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ПРЕДИСЛОВИЕ 


Р екс Блэк написал новую книгу! Читатели его первой книги “Мапаріпр 
е Тезвтя Ргосез5', несомненно, возлагали большие надежды на буду- 
щие произведения Рекса. И они не будут разочарованы его новой рабо- 
той “Ключевые процессы тестифования”. Он обратился к сложной теме и 
описал ее в доступной форме, чутко реагирующей на изменения контек- 
ста. Абстрактные на первый взгляд процессы тестирования оживают, и 
читатели могут разобраться в них и применить в собственных проектах. 

Некоторое время назад мы вместе с Рексом работали консультантами 
и читали цикл лекций. Приятно проводя время заужином, мы нередко бе- 
седовали о том, насколько близки наши взгляды по поводутого, как следу- 
ет проводить тестирование, что действительно имеет значение, а что 
нет. Когда пишешь книгу, легко увязнуть, пытаясь выделить все идеи, ко- 
торые представляются полезными для читателя. Порой при стремлении 
рассказать “все, что мы знаем” действительно важные мысли теряются в 
общей массе. Рекс успешно избежал этого, в чем и состоит прелесть дан- 
ной книги. Рекс рассмотрел весь имеющийся в его распоряжении значи- 
тельный и разнообразный опыт и описал 12 ключевых процессов. 

Эти процессы показаны достаточно подробно для того, чтобы пользо- 
ватель мог понять их, а при необходимости видоизменить и внедрить в 
своей компании. Рекс разъясняет процессы в эффективной, но необыч- 
ной манере. Сначала он демонстрирует их применение на примере дейст- 
вий вымышленной (но правдоподобной) проектной группы. Затем при- 
водятся общие положения каждого из этих процессов и даются советы, 
как их применять при смешении различных культур и условий. И нако- 
нец, каждый процесс “оживает” через личный опыт Рекса. Для того что- 
бы помочь читателю получить четкое представление о принципах тести- 


хім 


Предисловие 


рования, часто используются средства ыы графики, таблицы и 
примеры. 

Читателям вышедщей недавно книги “Зузетайс Ѕоўёшате Тезётр”, напи- 
санной мной в соавторстве со Стефаном Яскилем, известно, что несмот- 
ря на значимость инструментов, измерений и технических процессов, в 
конечном счете, по нашему мнению, качество программного продукта за- 
висит от людей. В “Ключевых процессах тестирования" особенно хорошо ос- 
вещено значение человеческого фактора, часто игнорируемого при соз- 
дании программного продукта, включая взаимодействие тестировщиков 
друг с другом и с группами и людьми, внешними для группы тестирова- 
ния. Рекс не рассматривает тестирование как обособленный вид деятель- 
ности, он показывает, как группа тестирования и отдельные тестировщи- 
ки работают в рамках процесса создания программного продукта в целом. 

Я работаю в сфере тестирования больше 20 лет и считаю это занятие 
благодарным и увлекательным. Но чтение книг на зту тему не всегда быва- 
ет столь же захватывающим. Однако неформальный, легкий для воспри- 
ятия стиль изложения Рекса превращает изучение ключевых процессов 
тестирования в несложное, полезное и даже веселое занятие! “Ключевые 
процессы тестирования” — одна изтех книг, которую тестировщики чита- 
ютоткорки до корки, а затем на нее часто ссылаются. Этой книге суждено 
стать классикой в области тестирования программного обеспечения. 


Рик Крэйг 

Консультант компании 

Ѕоћшате Оцаїйу Епріпегтіпр 

Автор книги “Систематическое 
тестирование программного обеспечения” 
Тампа, штат Флорида 


БЛАГОДАРНОСТИ 


та книга зародилась, когда Мэгди Ханна (Марду Наппа) предложила 

написать для журнала “/оитпа оў Ѕоћшате Тезійпр Ртојеѕѕіопаі5 серию ста- 
тей о процессах тестирования. Помимо этого журнала, части книги выхо- 
дили в виде статей в журналах “Рғојеѕѕіолаі Тезієт", “оўћшате Гіохій?' и “бойшате 
Теитв апа ди Шу Епрітеєтіпр"; в электронных журналах Ѕііскутіпдѕ.сот и 
Тех апа Меазигетепі.сога; и в виде главы книги Эрика Ван Веенендааля 
(Егік уап Усепепаааі) “Т#е Тезе Ргасійіопет". За рецензирование этих ран- 
них фрагментов книги я благодарю Роберта Кутрэ (Кобегі Сошге), Эстер 
Дерби (ЕѕіҺег Регбу), Брайана Хамблинга (Вгіап Нап! 15), Мэгди Ханну 
(Марду Наппа), Линду Хайес (Года Науеѕ), Брайана Лоуренса (Вгіап 
Гамтепсе), Брайана Марика (Вгіап МапсК), Дениса Мередита (Реп! 
Мегедїф), Джеми Митчелла (Јатіе МіёсһеШ), Каролайн Квентин (Сагоіпе 
Оцепйл), Лесли Сигала (ГезНе 5ераї), Ребекку Треджер (ВеБесса Тгаерег), 
Эрика Ван Веенендааля (Егік уап Уеепеп4а!) и Элина Уомбика (Ап 
М’атреке). Я также выражаю благодарность читателям этих отрывков и 
моей предыдущей книги “ Мапарілр іће Тезійто Руодесг, которые не пожалели 
времени, чтобы прислать мне комментарии и вопросы. 

Кроме того, в написание данной книги внесли свой вклад замечатель- 
ные люди из разных стран. Кто-то редактировал главы, по мере того как я 
их писал. Кто-то подавал идеи, приводил цитаты и примеры из жизни. 
Кто-то присылал заметки на полях. Хочу поблагодарить Сью Бартлет (5иє 
ВагПен), Ренделла Беккера (Капааії Вескег), Бориса Бейзера (Вогіѕ 
Веігег), Росса Колларда (Коз5 СоПага), Ли Копленда (І се Сореіапа), Рика 
Крейга (Кіск Сгаір), Гэри Доусона (Сагу Оомѕоп), Харви Дойча (Нагуеу 
Реџшіѕсһ), Тима Дайеса (Тіт Оуез), Криса де Нардиса (Сһгіѕ реМагаіѕ), 
Роджера Драбика (Кодрег ДгабісК), Дэнни Фота (Юаппу Еалё 1), Ларри 
Фзллоуза (Гаггу ЕеЦомз), Пэгги Футс (Реєру Еоисѕ), Нормана Хайнза 
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(Могтап Ніпеѕ), Кэти Айберли (Кау ІБегіє), Якоба Йенсена (ЈакоЬ 

Јерѕеп), Сема Канера (Сет Капег), Вайпула Кохера (У1рш Косһег), Тима 
Коомена, Филиппа Крушена (РЬШрре Кгисһ‹еп), Маркуса Манляйтнера 
(Магкоѕ Мапшекпег), Дарси Мартина (Рагсу Магіп), Жозе Мата (Јоѕе 
Мага), Деб Маккэндлз (реЬ МсСапез$), Дэйла Пэрри (РаІе Реггу), Эрика 
Петерсона (Егік Реіегѕоп), Джоанну Ротман, Барбару Руф (ВагБага Ки), 
Роберта Сабурина, Грега Скала (Сгер Зсаіа), Ребекку Совада (Кеђесса 
Зомада), Стива Сплейна (Ѕіеуе ЅрІаіп), Сербана Теодореску (Ѕеграп 
Теодогезси), Анни Цу (Аппе Тзои), Эрика Ван Веенендааля и Эда Уеллера 
(Еа МеПег). 

Наряду с работой над проектами и консультированием я занимался 
преподаванием ряда обучающих курсов. Многие рассматриваемые в кни- 
ге вопросы были темами этих курсов. Я призывал слушателей активно 
участвовать в занятиях, что они обычно и делали, делясь собственным 
опытом и описывая забавные случаи. Всех, посещавших мои курец ятак- 
же благодарю за вклад в эту книгу. 

До написания первой книги я даже не представлял, сколько работы в 
издательском бизнесе ведется за кулисами. Поскольку зто моя третья кни- 
га, я значительно лучше понимаю положение дел, и тем не менее уверен, 
что с некоторыми людьми, помогавшими донести до вас мои размышле- 
ния, я незнаком. Поэтому благодарю зсех работников компании Ад 4150п- 
Мез1еу, особенно Кима Эрни Малкачи (Кіт Агпеу МцісаПу), Марси Барнс- 
Хэнри (Магсу Вагпеѕ-Непгіе), Бернарда Гафни (Вегпага Са пеу), Питера 
Гордона (Регег Согдоп) и Дэбби Лафферти (РеБЫе Гайего). 

Наконец, последнее и самое главное. Я бесконечно благодарен своей 
семье. Процесс написания книги требует времени, не обходится без 
стрессов, а порой доводит до отчаяния. Мои родители, моя семья и родст- 
венники жены поддерживали и подбадривали меня. Дочки, Эмма и Шар- 
лота, вместе с нашими собаками, Максом и Космо, часто наблюдали за 
тем, как я писал эту книгу дома, и отпускали веселые комментарии. Благо- 
даря им, между очередными порциями ударов по клавиатуре я веселился, 
что было так важно! Последней (по порядкуупоминания, конечно, ане по 
значимости) назову мою жену Лорель, которая не только мужественно пе- 
реносит все тяготы положения жены “странствующего” консультанта, но 
и уже трижды пережила процесс создания книги. Лорель, ты лучше всех! 

Я благодарен всем, кто своим участием помог мне сделать книгу лучше. 
Если бы ни помощь названных мной людей, вкниге было бы хороших идей 
меньше, а плохих больше. Конечно, автор этой книги - я, и ответствен- 
ность за нее лежит исключительно на мне. Ошибки есть, и это мои ошибки. 
Направляйте, пожалуйста, комментарии, вопросы и критические замеча- 
ния по поводу этой книги на адрес Кех Віаск© КехВіаскСопѕшііпо.согт. 
Спасибо за чтение и удачи в ключевых процессах тестирования. 


ВСТУПЛЕНИЕ 


Ь олее 20 лет я занимаюсь тестированием программного и аппаратно- 
го обеспечения. Став тестировщиком, первые несколько лет я про- 
вел в борьбе за то, чтобы просто “удержаться на плаву”. В конце концов, я 
освоил некоторые основные инструменты и методы. 

_ По мере более глубокого погружения в тестирование я начал замечать 
некоторые общие проблемы. Ряд из них был связан с событиями (хороши- 
ми и плохими), повторяющимися вновь и вновь в проектах по созданию 
программ, аппаратуры и систем. При этом я обнаружил, что некоторым ко- 
мандам удавалось навести порядок в своих проектах. Такие команды лучше 
справлялись с типичными происшествиями, чем команды, постоянно ис- 
пытывающие кризисы, находящиеся в вечной борьбе, погруженные в 
хаос. Успешные команды использовали хорошие процессы. 

Некоторые успешные проектные группы внедряли процессы, зафик- 
сированные в письменной форме, сотрудники других удачливых команд 
держали “институциональные” знания в мудрых (порой поседевших 
раньше времени) головах. Не имея ничего против распространения кор- 
поративных культур, считаю, что трудно пользоваться уже освоенными 
процессами, если они не отражены в письменном виде, формально или в 
виде перечня контрольных вопросов. В этой книге избран неформаль- 
ный путь. Я описал 12 отдельных процессов тестирования, используя пе- 
речни контрольных вопросов. Каждый процесс является ключевым для 
успешной работы группы тестирования. 

Я описываю эти процессы в хронологическом порядке. Прежде всего 
мы планируем работы по тестированию. Затем ведем подготовку к тести- 
рованию. Далее. проводим тесты. И наконец совершенствуем систему, 
предназначенную для тестирования, и сами процедуры тестирования. 


Вступление 


Во многих других книгах подробно рассматриваются вопросы подго- 
товки и выполнения тестов. Потому, вместо того чтобы переформулиро- 
вать уже известное, я концентрирую внимание на возможностях усовер-. 
шенствования процессов. Одиннадцать из семнадцати глав посвящены 
вопросам планирования и совершенствования. Безусловно, именно сэти- 
ми направлениями связано большинство проблем, с которыми мы, тести- 
ровщики, сталкиваемся. Это особенно актуально в условиях сложных и 
критических проектов. 

Куда заведет вас эта книга? В начале колонизации Америки, в 1540-х, 
Франциско Васкес де Коронадо искал в пустынях на территории совре- 
менной Аризоны и Нью-Мексико страну Семи городов под названием Си- 
бола, включая Эльдорадо — город, улицы которого считались мощеными 
золотом. Жуан Понс де Леон вел поиски эликсира вечной молодости. 
В 1911 г. Фредерик Уинслоу Тейлор, один из первых специалистов по ме- 
неджменту, написал книгу под названием "Принципы научного менеджмен- 
та’. Тейлор придерживался идеи о существовании единственного 
лучшего способа — идеального процесса — для каждого вида производст- 
венной деятельности. Ни один из этих троих не нашел желаемого: улиц 
из золота, эликсира молодости, идеальных процессов. 

В этой книге нет поиска идеала. Не существует золотых улиц, которые 
позволят нам обогатиться без усилий. Мы не в силах преодолеть ограни- 
чения, наложенные человеческой природой. Я не предлагаю безупреч- 
ных процессов. Как написал Фредерик Брукс в книге “Мифический 
человеко-месяц”, у нас нет серебряных пуль, чтобы уничтожить монстров 
наших системных проектов, включая тех, что водятся в обеспечении ка- 
чества и в тестировании. Я узнал много способов, с помощью которых 
тестировщик может передать важную информацию и предоставить услу- 
ги рабочей группе проекта, и каждый из этих способов имеет свои силь- 
ные и слабые стороны. 

Процессы, описанные в книге, могут отличаться от тех, с которыми 
вы сейчас имеете дело. Может быть, основываясь на своем удачном опы- 
те, вы придете квыводу, что уже хорошо делаете свое дело. Тем не менее в 
некоторых случаях вам, возможно, захочется внести усовершенствова- 
ния. Я описываю конкретные способы, позволяющие это сделать, а две 
темы, касающиеся изменения процесса, рассматриваются на протяже- 
нии всей книги. 

Во-первых, полезно лишь изменение того, что уже идет наперекосяк. 
Изменение процессов ради самого изменения или совершенствование и 
без того хороших процессов зачастую не помогает группе тестирования 
или компании. На самом деле это может привести к серьезным отклоне- 
ниям от того, что действительно важно. 

Во-вторых, изменения нередко переносятся легче, если делать их по- 
этапно, там, где возможно. Изменения должны быть как можно менее бо- 
лезненными. Все процессы, описанные в зтой книге, были созданы благо- 
даря последовательным изменениям по мере того, как я понимал, что 
более удобный способ выполнения конкретной работы позволит сущест- 
венно увеличить вклад моей группы в общее дело, и точно настраивал 
процессы для достижения этой цели. 


Вступление хіх 


Процессы, описанные в книге, это не “журавль в небе”; они, скорее, 
выросли из моего опыта работы в качестве тестировщика, ведущего тес- 
тировщика и тест-менеджера. Ваш опыт и проблемы, с которыми вы стал- 
киваетесь, отличны от моих, потому будьте готовы адаптировать мой 
процесс или полностью придумать заново свой собственный и не пытай- 
тесь надеть на корову седло. Применение хороших процессов позволит 
вам освободиться от некоторых механических видов работы и сосредото- 
‘читься на интересных, приятных и творческих. Если привычные процес- 
сы перестают решать ключевые проблемы, если меняется ситуация и не- 
обходимы преобразования, значит нужно пересмотреть способы, с 
помощью которых вы делаете свое дело. Обсуждаемые здесь процессы 
предстают в форме списка контрольных вопросов (то, что я хочу не за- 
быть сделать), ане бюрократических правил (то, что я должен проделать, 
поскольку кто-то сказал мне об этом). 

Надеюсь, что, прочитав эту книгу, вы начнете задавать себе вопросы: 
“Как выполнять работы по тестированию наилучшим образом каждый 
день и в каждом проекте? Используем ли мы сведения о том, как мы дела- 
ем свое дело? Даже с учетом разнообразного опыта, разработана ли у нас 
совокупность мероприятий, способная при перенесении ее на критиче- 
ские процессы тестирования предопределить успешную работу?” Данная 
книга является кратким руководством по испытанным процессам тести- 
рования, которое призвано помочь запустить главнейший из ключевых 
процессов тестирования — мыслительный процесс. 


ВВЕДЕНИЕ 


В первом предложении “Анны Карениной” Лев Толстой пишет: “Все сча- 
стливые семьи похожи друг на друга, каждая несчастливая семья не- 
счастлива по-своему”. Бесспорно, Толстой создал великое произведение, 
написанное сильным языком и не оставляющее равнодушным, однако 
здесь он был не прав. Частности, касающиеся любой семьи, счастливой 
или несчастной, могут быть совершенно разными, но есть и некоторые об- 
щие причины несчастья. “Анна Каренина” — это история нелюбимого мужа 
и жены-обманщицы. Это две распространенные и взаимосвязанные беды, 
скоторыми сталкиваются семьи во всем мире. Для семейного счастья тоже 
существуют общие предпосылки, например здоровые дети, финансовое 
благополучие, любовь, взаимопонимание и общность интересов. 
Подобно семьям, компании представляют собой социальные группы; 


они также бывают счастливыми или несчастливыми, подчиняясь общим 
закономерностям. Сотрудники успешных компаний среди прочего до- 
вольны своей работой, стабильностью и возможностями карьерного рос- 
та. Работники неуспешной компании становятся несчастными, прилагая 
героические усилия и не получая достаточной отдачи, особенно когда ре- 
зультатом становится неудачный продукт. Одним из секретов успешной 
работы компании, занятой в области системных разработок и сопровож- 
дения продуктов, является грамотное применение хороших процессов, 
которые преобразуются с учетом конкретных условий успешными и ком- 
петентными специалистами и менеджерами. В книге “Ключевые процессы 
тестирования” я буду вашим проводником по 12-ти таким процессам для 
группы тестирования. , 
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Основные темы книги 


Что такое ключевой процесс тестифования? | Процесс — это совокупность дей- 
ствий, наблюдений й рещений, используемых для достижения желаемого: 
‚результата. Некоторые работы можно проводить одновременно, другие 
нужно осуществлять последовательно. Определенные виды деятельно- 
сти могут иметь единую цель, но применяемые в них технологии и ис- 
пользуемые навыки необязательно будут общими. Например, один из рас- 
сматриваемых ниже процессов — процесс управления сборкой тестовой 
версии программы — включает в себя выбор компонентов сборки, внесе- 
ние в нее изменений, создание сборки, подготовку установочного диска 
данной версии, установку новой тестовой версии и проведение приемоч- 
ного тестирования. 

Процесс является ключевым, если он соответствует одному из следую- 
щих критериев. 


я Группа тестирования, выполняя свою работу, вновь и вновь прибе- 
гает к данному процессу. Ясно определенный подход к повторяю- 
щимся процессам ведет к эффективному и последовательному вы- 
полнению повседневных обязанностей в сфере тестирования. 
Процесс составления отчета об ошибках, например, проводится 
снова и снова после выполнения тестов. 


и Процесс влияет на способность тестировщиков работать сообща, 
особенно если нарушение процесса может разрушить сплоченную, 
дружную команду. К примеру, если группа тестирования выполняет 
набор тестов, процесс должен поддерживать распределение кон- 
кретных заданий, предотвращая дублирование работ. 


и В процессе участвуют равные по должности или равные и выше- 
стоящие сотрудники. Группа тестирования, должным образом ра- 
ботающая с процессами, находящимися на виду, приобретает репу- 
тацию надежной и компетентной. Например, при составлении 
отчетов о состоянии тестирования тестировщики должны предос- 
тавить руководству и сотрудникам своего уровня сведения о проде- 
ланной работе таким образом, чтобы наиболее эффективно проин- 
формировать их о проведенном тестировании, выявленных 
проблемах и дать понять, что тестирование ценно как таковое. 


и Неудачное применение процесса способно повлечь за собой серь- 
езные, возможно, длительные негативные последствия. Рассмот- 
рим процесс отбора параметров конкретного продукта, подлежа- 
щих тестированию. Пропустив в результате неверно нацеленного 
тестирования основной вид критических для заказчика дефектов, 
получим, как минимум, неразбериху внутри компании и увеличе- 
ние затрат, а для некоторых видов систем возможно появление 
даже физической опасности для заказчика. 


Короче говоря, ключевые процессы непосредственно и существенно 
влияют на способность группы тестирования предоставлять значимые с 
организационной, операционной и технологической точек зрения ин- 


формацию и услуги. 


Введение 


Вообразите, что вы готовите торт, У вас есть ингредиенты (входные 
данные процесса), планируемая вечеринка (проект), голодные гости 
(проектная группа и другие заинтересованные стороны), кухня (контекст 
тестирования), рецепт (процесс тестирования). Торт, который вы хоти- 
те испечь, — это ожидаемый результат. Пропустите пару ингредиентов, 
решите, что одно из действий не существенно, легкомысленно отнеси- 
тесь к последовательности выполнения задачи, не придавайте значения 
тому, какие именно торты нравятся гостям. И в итоге на вечеринке поя- 
вится совсем не то кондитерское изделие. 

Не все действия в рамках проекта по созданию программного продук- 
та представляют собой процесс. Рассмотрим устранение ошибок — меро- 
приятие по ликвидации ошибки, описанной в отчете о найденных дефек- 
тах. Программист воспроизводит ситуацию, при которой происходит 
отказ, а далее для устранения дефекта не существует определенного прб- 
цесса. Имеются типичные инструменты, такие как отладчики и синтакси- 
ческие анализаторы. Есть эвристикӣ, применяемые программистами на 
основе собственного опыта в зависимости от симптомов отказа. Имеется 
также информация технического плана о типах ошибок, связанная с вы- 
бранным языком программирования, целевым окружением, компилято- 
ром ит.д. Но инструменты, эвристики и навыки не являются процессами. 
Устранение ошибок, скорее, напоминает поход за покупками, нежели 
приготовление блюда: вам надо лишь подвести к кассе тележку, в которой 
удобно расположены все товары из заранее составленного списка, опла- 
тить покупки и отправиться домой. 

Я намеренно выбрал эти два примера. Считается, что эти процессы скуч- 
ные. Что они требуются только людям, не обладающим необходимыми на- 
выками. Что в них нет творческого начала. Я с этим не согласен. Что может 
быть более созидательным, чем кулинария или выбор покупок? С чем спра- 
виться труднее? Что приносит больше удовлетворения? Точно так же я нахо- 
жу процесс составления отчетов об ошибках интересньм, требующим пол- 
ной отдачи творческим делом, занимаясь которьм я вспоминаю, почему 
принял решение стать тестировщиком. Напротив, когда я пишу программу, 
устранение ошибок всегда заставляет вновь и вновь почувствовать утомле- 
ние и неудовлетворенность от кодирования. Именно это и подтолкнуло 
меня оставить программирование и стать тестировщиком. 


Предполагаемый круг читателей 


Эта книга для всех тестировщиков, которые стремятся улучшить свою ра- 
боту. Это книга для ведущих тестировщиков, тест-менеджеров, менедже- 
ров по созданию программного продукта, отвечающих за тестирование, 
и для всех, в чьи обязанности временно или постоянно входит обеспече- 
ние того, чтобы такой элемент проекта по созданию или сопровождению 
системы, как тестирование, велся успешно. Она предназначена для лю- 
дей, ответственных за повышение квалификации тестировщиков или 
улучшение работы групны тестирования в целом. Для всех, кто связан с 
тестированием, для организаций, уже внедривших ряд основных процес- 
сов тестирования (возможно, на базе идей, предложенных в моей преды- 
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дущей книге “Мапартр іће Тезіїпу Ргосезу"), а теперь ищущих пути их совер- 
шенствования. Если эта книга найдет отклик на уровне высшего звена 
менеджмента или дирекции, то она способна вывести вашу группу тести- 
рования вавангард сообщества тестировщиков и принесет значительную 
отдачу на вложенные в тестирование средства. | 

В отличие от большинства других книг по тестированию программно- 
го обеспечения, которые рассматривают прежде всего технические ас- 
пекты выполнения конкретных задач, эта книга, кроме всего прочего, по- 
может вам понять более широкий контекст, в котором и для которого 
осуществляется тестирование. Эта книга не является продолжением 
моей первой книги “Управление процессом тестирования”. Там я рассматри- 
вал процесс в целом, его ключевые задачи и процедуры с технической 
точки зрения. “Мапаріпо ће Тезійпр Ргосезз” отличается от прочих книг, по- 
священных этой теме, поскольку она писалась с учетом потребностей 
тест-менеджера, но, как и они, в первую очередь направлена на решение 
тактических задач. Подобные, посвященные тактике, книги весьма по- 
лезны при выполнении конкретных задач, но нуждаются в рассмотрении 
более широкой перспективы. Именно это вы и получаете при чтении 
“Ключевых процессов тестирования”. В данной книге рассматривается про- 
цесс тестирования в целом и каждый входящий в него ключевой процесс. 
В центре внимания находятся процессы (конкретные способы, с помо- 
щью которых тестировщик предоставляет полезную информацию и услу- 
ги в рамках проекта), связывающие воедино конкретные задачи и дейст- 
вия, которые мы выполняем повседневно. Независимо от позиции, 
которую вы занимаете в сфере тестирования: от инженера-тестировщика 
до руководителя сотнями тестировщиков, — “Ключевые процессы тести- 
рования” помогут вам получить новое представление о внутренних аспек- 
тах вашей деятельности, о ее значении и о том, как работать лучше. 


Снимем с процессов покров тайны 


Я прочел несколько книг, посвященных совершенствованию процесса 
создания программного продукта, которые, честно говоря, меня озадачи- 
ли. Я читал и читал, но по завершении чтения не имел ни малейшего 
представления, как применить идеи, с которыми только что познакомил- 
ся. Эта книга, в отличие от других книг, посвященных процессам, не запу- 
тает вас. Рассказывая о том или ином процессе, я даю пример гипотетиче- 
ской учебной ситуации, которая рассматривается на протяжении всей 
книги. Затем я даю некоторые советы по поводу поведения и достижений 
групп тестирования, использующих хорошие процессы, по поводу того, 
как справляться с трудностями в процессе и как внедрить усовершенство- 
вания. Эти общие идеи я “приправляю” конкретными примерами из соб- 
ственного опыта. Так что процессы обретают плоть и кровь. 

Чтобы не усложнять объяснения, я представляю процессы в виде спи- 
сков контрольных вопросов. Это полезный и легкий способ организации 
тестирования, ориентированного на процесс. Кроме того, вопросы по- 
зволят вам собирать данные и совершенствовать процессы, поскольку вы 
начнете контролировать происходящее. Чтобы связать обсуждение кон- 
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кретных и общих вопросов с частными элементами каждого процесса, о 
котором идет речь, я буду использовать таблицы, аналогичные таблице 
для процесса 1. і 


Процесс 1. Этап 1 процесса тестирования 


№ этапа Этап Выполнено? 
1. Планирование: понимание места тестирования. . О 
ІА Определить функциональный (система, проект и процесс) а 
и организационный контексты, в рамках которых выполняет- 
ся тестирование. 
1.В Определить и расставить приоритеты рисков качества систе- го 


мы, достичь консенсуса заинтересованных сторон проекта от- 
носительно возможностей тестирования по смягчению этих 
рисков. 


С Оценить временные, ресурсные и финансовые затраты, необ- | О 
ходимые для выполнения тестирования и согласованные 
с пунктом 1.В, получить поддержку оценки у руководства. 
1.0 Запланировать задачи, зависимости и состав участников, кото- о 
рые необходимы для смягчения рисков качества системы, и по- 
лучить поддержку плана у заинтересованных сторон проекта. 


Процессы имеют сквозную нумерацию по всей книге. Хотя вам, несо- 
мненно, придется перекраивать эти списки контрольных вопросов для 
нужд тестирования в своих проектах, вы можете получить их вместе с дру- 
гой вспомогательной документацией бесплатно на сайте уугу.гехБіасК- 
сопѕиііпе.сот. Загрузите их и переделайте, как вам угодно, в соответст- 
вии с лицензией, которая загрузится вместе с этими документами . 


Виды ключевых процессов: тестирования 
и их взаимосвязь _ 


Некоторые ключевые процессы тестирования являются внутренними 
для группы тестирования, проводятся исключительно силами тестиров- 
щиков и влияют только на них. Другие процессы — совместные, в них 
включены другие группы компании. Я использую слово “совместные”, 
ане “внешние”, поскольку эффективно взаимодействующие групцы пред- 
варительно принимают работу друг друга. Если группы перебрасывают 
неполные и недоброкачественные объекты через организационные “сте- 
ны”, это является отличительным признаком слабой командной работы. 
Совместный процесс может включать в себя прием или предоставление 


Й 


Не волнуйтесь! Для чтения этой книги вам вовсе не обязательно быть гуру в области ЗЕ 
СММ, 150 9000, КОР и других процессов. Если вы в состоянии справиться с инструкцией по 
сборке трехколесного велосипеда или приготовить цьшленка в тандуре, то для вас не соста- 
вит труда понять идеи книги, опирающиеся на списки контрольных вопросов и оживлен- 
ные описанием практических ситуаций, независимо от того, знакомы вам или нет подобнне 
подходы к работе. 
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передаваемых объектов или и то и другое. При совместном процессе мо- 
жет появиться совокупность передаваемых объектов, связывающих мно- 
жество команд. З 

Любой ключевой процесс зависит от контекста, в рамках которого он 
проходит. То есть процесс должен соответствовать участвующим в нем 
людям, системе, проекту и компании. В ситуации, зависящей от контек- 
ста, едва уловимые факторы могут повлечь за собой последствия, жела- 
тельные в одном случае и нежелательные в другом. Например, бросать 
еду через плечо, как правило, не стоит, однако это может оказаться впол- 
не приемлемым, если в качестве еды выступает просыпанная соль, а во- 
круг вас — суеверные люди. Рассмотрим пример окружения процесса тес- 
тирования. Предоставление отчетов о результатах тестирования группе 
управления проектом требует хороших навыков в общении, ведь нужно 
чувствовать, что, когда и кому сказать. 

Тестирование в ракурсе проекта связано с множеством различных ви- 
дов деятельности и групп. На рис. 1.1 упрощенно показаны ряд процессов 
(стрелки) и групп (круги), участвующих в процессе разработки программ- 
ного обеспечения в ходе выполнения тестов. 

Выполнение тестов является здесь внутренним процессом, поскольку 
отслеживает результаты цикла тестирования. Предоставление отчетов 
об ошибках является совместным процессом, в ходе которого группа тес- 
тирования передает группе разработчиков информацию, получаемую в 
процессе проведения тестов. Аналогично, отправка перечня изменений 
для конкретной тестовой версии представляет собой совместный про-. 
цесс передачи группой разработчиков группе тестирования информа- 
ции, требующейся в процессе проведения тестов. В виду того, что про- 
цесс подготовки отчетов о состоянии тестирования зависит от 
контекста, тест-менеджер сообщает группе управления проектом о про- 
движении работ по тестированию и о том, как идет оценка качества про- 
граммного продукта, прибегая к графикам и измерениям, понятным дан- 
ной группе и подходящим для нужд процесса разработки. И наконец, 
обратите внимание на многоступенчатый совместный процесс передачи 
версии программного продукта группе тестирования, который был раз- 
бит мной на совместные подпроцессы, показанные в круглых скобках. 

Многие передаваемые объекты и зависимости должны по времени и 
по форме аккуратнейшим образом сходиться в одной точке -- на группе 
тестирования. Только в этом случае она сможет своевременно предостав- 
лять точную, полную и надежную информацию и соответствующие услуги 
по тестированию. Подобные совместные процессы относятся к наиболее 
критическим. Точно так же влияние контекста часто скрыто и трудно раз- 
личимо. Прежде чем принять решение по поводу надлежащего процесса, 
тестировщики должны внимательно изучить происходящее, поскольку 
реальное положение дел может существенно отличаться от того, что го- 
ворят или думают об этом другие. Контекстно-зависимый и совместный 
характер многих процессов усложняет их проведение, поскольку в груп- 
пах возникает необходимость адаптировать и перестраивать процессы 
для того, чтобы удовлетворить взаимные потребности или чтобы под- 
строиться под изменившуюся ситуацию, а это требует использования ди- 
пломатии, проведения переговоров и координации усилий. 
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Рис. 11. Поиск ошибок и их устранение с точки зрения процесса 
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Кроме того, тесная связь между самими процессами тестирования и 
между процессами тестирования и другими процессами в проекте порож- 
дает взаймозависимость. Каждый процесс влияет на ход проведения и ре- 
зультат всех остальных процессов. В итоге устанавливаются петли обрат- 
ной связи. Проницательные тестировщики могут их использовать для 
расширения своего влияния. Приведу пример. 

На рис. 1.1 видно, что качество процесса подготовки отчетов об ошиб- 
ках влияет на качество отчетов о состоянии тестирования, передаваемых 
руководству. Проектная группа оценивает качество отчетов о состоянии 
тестирования часто на основании того, содержат ли данные отчеты по- 
лезную для нее информацию. При этом имеет значение не только объек- 
тивная “полезность”, но и ее восприятие. Если отчеты о состоянии тести- 
рования действительно полезны и воспринимаются как полезные, то 
складывается мнение, что в тестирование выгодно вкладывать средства. 
Подобное отношение, в свою очередь, укрепляет доверие кгруппе тести- 
рования, в результате чего она получает больше необходимых для работы 
ресурсов. Эти ресурсы являются предпосылкой для хорошего проведе- 
ния процессов тестирования, включая подготовку отчетов об ошибках. 


Ключевые процессы тестирования, 
взятые в контексте 


Ключевые процессы тестирования протекают в контексте проекта тести- 
рования, который в свою очередь входит в объемлющий проект разра- 
ботки, сопровождения, интеграции и приемо-сдаточных испытаний сис- 
темы. Выявление и изучение ключевых процессов тестирования 
позволяет наилучшим образом выполнять проекты тестирования. По 
мере того как мы будем исследовать процессы в контексте подпроекта 
тестирования, не забывайте, что мы наблюдаем за совокупностью актив- 
ностей, которые со временем завершаются и предоставляют проектной 
группе на протяжении всего проекта информацию и полезные услуги тес- 
тирования. Поэтому я буду исследовать ключевые процессы тестирова- 
ния в хронологическом порядке: планирование, подготовка, проведение 
и совершенствование. 
_ Часть І — Планирование — описывает эти процессы. 


1. Вникните в операционный (система, проект, процесс) и организа- 
ционный контексты предстоящего тестирования. · 


2. Определите риски качества системы и проранжируйте их; добей- 
тесь, чтобы все заинтересованные стороны пришли кединому мне- 
нию по поводу объема и охвата тестирования, это позволит сни- 
зить риски. 


3. Оцените потребности во временных и людских ресурсах ивденеж- 
ных средствах на проведение тестирования в оговоренных ранее 
рамках и заручитесь поддержкой руководства. 


4. Разработайте план мероприятий, состав участников, определите 
взаимозависимости, необходимые для проведения тестирования, 
и добейтесь поддержки этого плана у заинтересованных сторон. 
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Часть П — Подготовка — исследует данные процессы. 


`5. Привлеките в команду новых тестировщиков и добейтесь повыше- 
ния квалификации группы тестирования. То есть посредством най- 
ма и обучения обеспечьте наличие необходимых навыков у ее уча- 

стников, добейтесь надлежащего отношения к делу и мотивации. 
6. Спланируйте, создайте, проверьте и утвердите систему тестирова- 
ния (тестовые сценарии, тестовые данные, инструменты тестиро- 
вания, среда тестирования, процедуры проведения тестов и т.д.), 
которой будет придерживаться группа тестирования для оценки ка- 

‚ чества тестируемой системы. 


В части П - Проведение —– вы столкнетесь со следующими процессами. 


7. Получите и установите версию для тестирования, содержащую не- 
которые или все компоненты тестируемой системы. 

8. Определите, проведите, последите и осуществите руководство 
комплектом тестов, предназначенным к исполнению в каждой тес- 
товой версии. ` 


Часть ГУ — Совершенствование — обсуждает остальные процессы. 


9. Документируйте ошибки, выявленные в ходе проведения тестиро- 
вания. 


10. Проинформируйте основные заинтересованные стороны о резуль- 
татах тестирования. 


11. Подстройтесь под изменения контекста проекта и усовершенствуй- 
те процесс тестирования. 


Гипотетический проект “Суматра” 


Для иллюстрации процессов на протяжении всей книги используется вы- 
думанный проект. Данный проект представляет собой новую версию 
бреедуМ ег — приложения по обработке текстов на основе браузера, ко- 
торое работает в основных међ-браузерах и поддерживается операцион- 
ными системами МЙпдомз, Глпих, 50іагіз и Мас. Приложение реализовано 
на Јауа, использует уеб-сервер, сервер приложения, а также файловый 
сервер и сервер баз данных. Разработчиком Зрееду\Мтиег является 
Зоймаге Сабегегіа — средних размеров компания, которая занимается раз- 
работкой программного обеспечения и располагается в Остине, штат Те- 
хас. Ѕоймаге Саѓеѓіегіа работает над версией 3.1 данного продукта, полу- 
чившего кодовое название “Суматра” (Ѕитаќга). Выпуск версии на рынок 
США по графику намечен на начало следующего года, в последующие 3 — 
6 месяцев планируется выпустить версии для основных иностранных 
рынков!. 


1 Именаи фамилии участников учебной ситуации отражают соотношение половой и на- 
циональной принадлежности, обычное для мира высоких технологий. Я придумывал участ- 
ников, диалоги и рассказы, исходя из моего профессионального опыта. 


Часть 11. Подготовка: 


‚ Я стремлюсь следовать структурированному, хорошо документиро- 
ванному подходу к тестированию в большинстве проектов. Выбранный 
мной в качестве примера проект иллюстрируется различными цифрами 
и таблицами, взятыми из документов. Эти документы можно бесплатно 
скачать с моего сайта. Таким образом, изучаемый пример является одно- 
временно и рассказом-описанием, и комплектом передаваемых докумен- 
тов тестирования. Вы имеете возможность ознакомиться с учебной ситуа» 
цией, принять решение об использовании предложенного мной 
процесса и получить некоторые инструменты для претворения данного 
процесса в жизнь. Я приложил много сил, чтобы эти документы были ка- 
чественными и могли бы стать для вас важным подспорьем . 


Терминология 


Читая данную книгу и изучая документы, вы можете встретить незнако- 
мые термины, а также знакомые термины, употребляемые мной в значе- 
нии, отличном от того, к которому вы привыкли. В мире тестировщиков 
существует много диалектов. У нас нет общепринятого словаря, не огово- 
рен и минимально необходимый набор знаний, что приводит к трудно- 
стям при обсуждении того, чем мы занимаемся. У бухгалтеров есть обще- 
известные бухгалтерские проводки и операции. Доктора пишут диагнозы 
в медицинских картах пациентов, а другие врачи понимают сделанные за- 
писи и используют те же названия для обозначения соответствующих 
проблем. А мы, тестировщики, пока не имеем такой возможности. 
Поэтому каждый раз, прибегая к термину, который, как мне кажется, 

может внести неразбериху, я формулирую, что под ним понимается. Я не 
пытаюсь создавать определения, а лишь хочу познакомить вас с моими опре- 
делениями. Они представлены в виде врезок обособленного текста недале- 
ко от того места, где тот или иной термин впервые встречается в книге. 
Для примера здесь приводится определение термина “система”, Все опре- 
деления собраны в глоссарии, приведенном в конце книги. 


Относительно использования данной книги 


В процессе чтения этой книги вы познакомитесь с процессами, изучите 
учебную ситуацию и примеры и развеете все неясности по поводу исполь- 
зуемых мною терминов. Значит ли это, что, завершив чтение, вы будете 
готовы к тому, чтобы немедленно начать стремительные изменения в 
процессах тестирования, как в ваших личных, так и для всей группы? Не 
совсем. Не так быстро. Как уже говорилось, многие процессы тестирова- 


ния, в том числе ключевые, о которых я буду рассказывать, являются 


контекстно-зависимыми. Стремясь помочь вам проложить курс на улуч- 


1 Замечу, что эти документы относятся квымышленной учебной ситуации. Данные и изме- 
рения разумны, но, возможно, ваши измерения будут ‘существенно отличаться от приведен- 
ных в книге. Кроме того, данные, используемые мной в различных примерах, приведены в 
объеме, необходимом лишь для пояснения положений, о емых в книге, и ие более 
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щение процесса, я завершаю обсуждение каждого процесса тремя основ- 
ными разделами. 


Построение успешного процесса 


Как определить успешные процессы? Можно выявить поведение группы 
тестирования иее достижения, указывающие на степень успешности про- 
цесса. Иными словами, что делает группа тестирования, когда применяет 
успешные процессы, и какие преимущества она от этого получает? Если, 
к примеру, вы начнете заниматься физическими упражнениями по опре- 
деленной программе, то, достигнув успеха в этом деле, вы получите увели- 
чение мышечной массы, снижение жировой прослойки и станете вынос- 
ливее. Для закрепления и углубления полученных результатов вы, 
возможно, начнете заниматься спортом на регулярной основе, правиль- 
но питаться и бросите курить. В тех 12 процессах, что нам предстоит рас- 
смотреть, подобные действия и достижения находятся во взаимодейст- 
вии и подпитывают друг друга. 

Как правило, существует целый спектр подобных действий и достиже- 
ний. Например, занимаясь по оздоровительной программе около 8 лет, 
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я продолжал курить. При этом я действительно добился поставленных це- 
лей. Однако, беспокоясь о влиянии курения на здоровье в долгосрочной 
перспективе и будучи несколько удивлен низкой выносливостью при 
беге, я бросил курить. В результате всего через пару месяцев я стал пробе- 
гать милю на минуту быстрее. 

Как понять, как работают ваши текущие процессы? Возможно, в изме- 
нениях нет необходимости. Как узнать, позволит ли контекст успешно 
внедрить предполагаемые изменения? В этом вам помогут разделы, по- 
священные построению успешных процессов. 


Решение проблем 


Во многих случаях складываются ситуации, способные создать преграды 
и помехи для конкретных процессов. Типичным примером являются не- 
реалистичные ожидания со стороны руководства. Некоторые считают, 
что тестировщики прячут в рукавах коробочки с волшебным порошком. 
Стоит только посыпать этим порошком систему, и все ошибки вылезут на- 
ружу. Кто-то из руководителей примет реалистичное объяснение, каким 
на самом деле может быть вклад тестирования в проект. Другие будут на- 
стаивать на том, что хорошо справляющиеся со своим делом тестировщи- 
ки способны устранить все проблемы. Подобные ожидания чрезвычайно 
осложняют переговоры с руководством по поводу принятия им реали- 
стичных графика и бюджета тестирования. Если вы намерены внести из- 
менения в организацию и в способ проведения тестирования, очень важ- 
но понять эти трудности и знать, как с ними бороться. 


Внедрение усовершенствований 


Улучшение процесса нередко является сложной задачей. Например, вне- 
дрение выстроенного процесса управления дефектами, включая грамот- 
ный выбор подходящего инструмента по отслеживанию ошибок, может 
потребовать лично от вас нескольких недель, а в целом занять больше ме- 
сяца. Кроме того, наряду с практическими действиями требуется еще и 
умение убеждать. Порой получить согласие на внесение изменений в про- 
цесс сложнее, чем изменить его. Часто подавляющее большинство ратует 
за сохранение статус-кво и не поддерживает ваших предложений, какими 
бы хорошими они ни были. Поэтому, поставив цель что-то изменить, вам 
придется идти на риск, обосновывать изменения и прикладывать много 
сил, чтобы дело не застопорилось. Наконец, процесс усовершенствова- 
ния требует наличия продуманного плана действий. Существует даже 
процесс для достижения изменений в процессе! Я не могу дать рецепт, ко- 
торый сработает в любых обстоятельствах, но постараюсь изложить не- 
которые идеи, над которыми стоит поразмышлять, планируя преобразо- 
вания. =. 5, З ув 

Процессы не гарантируют успеха, а, скорее, подготавливают для этого 
почву, при условии, что они подготовлены должным образом. Неверно 
разработанные процессы могут стать обременительными и потребовать 
много сил и времени на бумажную волокиту. К. примеру, после переезда 
я попытался сменить мой рабочий адрес у моего бывшего регистратора 
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домена ОВГ. Чтобы добиться желаемого, я в течение полугода отправил 
более двадцати факсов и электронных писем. В конце концов, я сдался и 
сменил регистратора. Процесс, существующий у нового регистратора, со- 
ответствовал моему представлению о качественном обслуживании. Разу- 
меется, мы не хотим чинить препятствия на пути к предоставлению каче- 
ственных услуг по тестированию. Идея состоит в том, чтобы и процесс, 
и структура присутствовали в оптимальном объеме, ни больше, ни мень- 
ше, выступая основой для действительно блестящей работы и ОНИ 
вая ее. 

Но наряду с использованием верного подхода к изменению процесса 
вам потребуется выбирать, к чему прикладывать силы. Если, прочитав по- 
следнюю страницу, вы решите немедленно изменить каждый из обсуж- 
даемых в книге процессов, вас ждет поражение. Что еще хуже, эта неудача 
приведет к путанице в тех делах, которые прежде шли хорошо, а это, ве- 
роятно, будет стоить вам “потери лица”. Поэтому в конце книги я расска- 
жуо том, как планировать надлежащие изменения в процессах, более все- 


го в них нуждающихся. 


Успехов на ниве тестирования! 


‚Если предметом данной книги являются процессы тестирования, то в ка- 


честве цели чтения выступает понимание того, как добиться больших ус- 
пехов в выполнении проектов тестирования. Процессы являются всего 
лишь средством для достижения этой цели. Так, большинство людей со- 
бирают кулинарные книги не для того, чтобы они пылились на полках. 
Они покупают эти книги, чтобы успешно приготовить то или иное вкус- 
ное блюдо. Заглянув ко мне на кухню, вы легко догадаетесь, какие из кули- 
нарных книг мои любимые. Они пахнут специями, забрызганы расти- 
тельным маслом и потрепаны от частого использования. Они сразу 
откроются на страницах с моими любимыми рецептами, по хоторни я 
люблю готовить снова и снова. 

Шеф-повара ценят не за следование процессам приготовления блюд. 
Его мастерство не измеряется строгостью следования рецептам. Шеф- 
повар окажется мастером своего дела, если вновь и вновь будет преподно- 
сить гостям лакомые блюда в оговоренное время и за разумные деньги, 
потраченные на качественные продукты. 

Точно так же данная книга призвана помочь вам добиться успеха в роли 
тестировщика. Надеюсь, что с годами она также обзаведется пометками, 
потрепанными страницами, а возможно, от частого использования кое-где 
порвется. Надеюсь, что приведенные мной списки контрольных вопро- 
сов, образцы и примеры станут вашими излюбленными “кухонными при- 
надлежностями” для приготовления успешного проекта тестирования. 
Я буду считать, что написал удачную книгу, если она поможет вам стать бо- 
лее уверенными и успешными профессионалами в области тестирования. 


Планирование 


В 


щей части книги - подготовке успешного тестирования. 


№ этапа Этап 


1. 
1.А 


Определить функциональный (система, проект и процесс) 


1.В 


1.С 


1.р 


лучить поддержку плана у заинтересованных сторон проекта. 


Планирование: понимание места тестирования. 


и организационный контексты, в рамках которых выполняет 
ся тестирование. 


Определить и расставить приоритеты рисков качества систе- 
мы, достичь консенсуса заинтересованных сторон проекта от- 
носительно возможностей тестирования по смягчению этих 
рисков. 


Оценить временные, ресурсные и финансовые затраты, необ- 
ходимые для выполнения тестирования и согласованные 
с пунктом 1.В, получить поддержку оценки у руководства. 


Запланировать задачи, зависимости и состав участников, кото- 
уча 
рые необходимы для смягчения рисков качества системы, и по- 


первой части книги мы исследуем процессы, связанные с понимани- 
ем того, какие работы по тестированию нужно выполнить. Это са- 
мая большая по объему часть книги, поскольку на этом этапе процесса 
тестирования мы закладываем основы успеха. Сначала мы исследуем ме- 
сто работ по тестированию в проекте, затем изучим риски, которые тес- 
тирование позволяет снизить. Заложив фундамент, мы исследуем еще два 
процесса: оценку и планирование. Разобравшись с графиками и затрата- 
ми и оставив позади детали стратегии и тактики, мы перейдем к следую- 


Выполнено? 


и) 
и 


ГЛАВА 1 


Панорамный обзор: 
роль тестирования в более 
широком контексте _ 


3 ачем мы здесь? Нет, я не спрашиваю, зачем люди живут на Земле; 
я спрашиваю, зачем компании финансируют проекты, которые тре- 
буют тестирования? 

Компании разрабатывают, сопровождают или приобретают системы, 
чтобы поставлять какие-либо значимые продукты, услуги или возможно- 
сти для некоторой группы клиентов, пользователей и других заинтересо- 
ванных лиц. Передаваемые ценности приобретают различные формы: от 
развлечений (видеоигры) до производства (офисные приложения), от 
обороны (системы вооружений) до борьбы с заболеваниями (медицин- 
ские устройства). Заказчики, пользователи и другие заинтересованные 
лица ожидают (обоснованно и не очень) получить систему определенно- 
го качества. Масштаб этих ожиданий простирается от “хотя бы как-то ра- 
ботало” до “полное отсутствие дефектов”. В целом заказчики, пользовате- 
ли и другие заинтересованные лица рассчитывают, что системы будут 
демонстрировать преимущественно удовлетворительную работу. 

Даже искренне добиваясь высокого качества в ходе разработки систе- 
мы, ее сопровождения и поставки, люди совершают ошибки. Эти ошибки 
снижают уровень качества системы относительно ожиданий. Разница ме- 
жду ожидаемым качеством и получаемым качеством проявляется в рис- 
ках для компании-разработчика, а также для заказчиков, пользователей 
и других заинтересованных лиц. 

Эти риски могут мотивировать компанию на инвестиции, связанные 
с качеством, включая инвестиции в качество. В частности, организации 
могут направить усилия на: 


= Уменьшение общих затрат, связанных с проблемами качества 
и Повышение доверия к функциям системы 


= Снижение вероятности событий, угрожающих прибыли, достиже- 
нию цели и даже жизни 


Часть [. Планирование 


и Повышение репутации компании касательно качества самой систе- 
мы и качества продуктов и услуг, которые она поддерживает 


в Получениє повторных и связанных заказов от удовлетворенных ра- 
ботой компании заказчиков 


и Снижение числа судебных исков из-за дефектов системы (для ком- 
паний-разработчиков) и исков заказчиков (для контролирующих 
компаний) 


Первое определение взято из книги Дж. М. Джурана (]. М. Јигап) “итап оп Ріатпіта јот 
Оцаїну'. Второе определение позаимствовано из книги Филипа Кросби (РЫШр СгозЪу) 
"Оцаїйу 15 Ег. Определение Кросби неявно следует из определения Джурана в случае, если 
процесс сбора требований организован и выполнен верно. Если в ходе процесса сбора тре- 
бований были допущены отклонения, второе определение менее полезно. Однако в случае 
разработки заказных проектов имеет больший смысл рассматривать качество как соответ- 
ствие требованиям и увязьвать контракт, требования и тестирование с учетом данного оп- 
ределения. 
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ш Соблюдение плановтрафиков, бюджетов или достижение целей, 
связанных с промышленными стандартами, для рабочей версии 
или поставки системы 


и Повышение качества планирования, графиков и бюджетов для бу- 
дущих проектов 


и Получение финансов для текущих и будущих проектов 


и Снижение вероятности несдачи системы заказчику, что может не- 
гативно сказаться на конкурентоспособности компании 


Мотивация может зависеть от того, говорим мы о тестировании сила- 
ми компании-разработчика, создающей систему, или о тестировании си- 
лами внешней компании, рассматривающей вопрос о приобретении, ин- 
тегрировании или поставке системы . 

Хотя данные предыдущих проектов и модели могут оказать помощь 
в прогнозировании числа дефектов (см. главы 3 и 4), точное число, рамки, 
серьезность и локализация проблем качества не известны заранее. Таким 
образом, эти потенциальные проблемы являются рисками (вероятными 
негативными результатами или событиями). Риски подвергают опасности 
качество системы. Эффективно организованное тестирование предостав- 
ляет услуги и информацию, способствующие управлению рисками качест- 
ва разрабатываемой, сопровождаемой или поставляемой системы. 

Для предоставления компании услуг тестирования и информации слу- 
жат процессы тестирования в рамках проектов разработки, сопровожде- 


Индивидуальные покупатели программных средств редко обладают правом в рамках со- 
глашения о приобретении проводить приемочные тесты любого вида. В ходе разработки 
большинство контрактов на приобретение прикладных программ явно исключают подоб- 
ные тесты. Для изучения этой и других диспропорций в распределении стоимости продук- 
тов низкого качества на рынке прикладных программ я рекомендую просмотреть некото- 
рые из работ Сема Канера (Сеш Капег), в том числе “Вай 5о/їшаті", и его статьи на сайте 
угили капег.сот в разделе ОСГТА (ОпНопи Сопарщег Іпѓогтайоп Тгапѕасііорѕ Асі). 


Часть 1. Планирование 


ния или поставки системы. (В компаниях, в которых есть отдельно рабо- 
тающие группы тестирования, некоторые активности выступают в 
качестве отдельных подпроектов, выполняемых такими группами.) Про- 
цессы тестирования — это последовательности действий, работ и наблю- 
дений, предпринимаемых для достижения цели. На самом верхнем уров- 
не процесс тестирования состоит из четырех шагов, которые могут 
накладываться друг на друга. 


1. Планирование — понимание места тестирования. 
2. Подготовка— сбор людей и тестов. 


3. Проведение — выполнение тестов и сбор результатов. 


4. Совершенствование — предоставление информации о проекте и его 
улучшение. 


В идеале процесс тестирования начинается одновременно с возникно- 
вением замысла системы и продолжается до конца жизненного цикла сис- 
темы (т.е. до списания, завершения существования или окончания под- 
держки системы). 

Процесс тестирования представлен на рис. 1.1. Если вы изучали то- 
тальное управление качеством (гогаї доаіу тапаретеп®), то, вероятно, 
узнаете показанный на рисунке цикл как разновидность процесса “план, 
осуществление, проверка, действие” для непрерывного совершенствова- 
ния качества, описанного Э. Демингом!. При грамотном проведении тес- 
тирования в ходе всего жизненного цикла системы не только непрерыв- 
но улучшается система, но в качестве желаемого побочного эффекта 
процесс тестирования поставляет информацию о других процессах жиз- 
ненного цикла. Проектная группа может применять эту информацию для 
улучшения соответствующих процессов. 

Ранее я перечислил несколько возможных мотивов проведения тести- 
рования. Как именно процесс тестирования обеспечивает возврат вложе- 


1 сы. Мэри Уолтон (Магу Макоп) “Те Детіпр Мапаретепі Меїйод". 
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Понимание места 
тестирования 


Сбор людей и тестов 


• Создание группы 
тестирования 

* Проектирование и разработка 

системы тестов 


• Изучение контекста 
тестирования 

. Анализ рисков качества 

• Оценка объемов 
тестирования 

~ Планирование тестирования 


Предоставление информации 


о проекте и аго 
совершенствование 


Выполнение тестов 
и получение результатов 


• Получение тестовой версии 
• Прогон тестов и отслеживание 
результатов 


• Подготовка отчетов 
о любых дефектах 
« Подготовка отчетов 

о результатах тестирования 
| * Управление изменениями 


Рис. 11. Процесс тестирования 


ний в него? В большинстве проектов тестирования это происходит че 
тырьмя основными способами: 


1. Обнаружение ошибок, которые будут устранены, или даже предот- 
вращение их внесения. 


2. Обнаружение ошибок, которые не будут устранены, но о которых 
становится известно. 


3. Проведение тестов, которые снижают (потенциально затратные) 
риски. 


4. Обеспечение проекта своевременной, точной и заслуживающей 
доверия информацией. 


Группа тестирования привносит в проект эти преимущества в основ- 
ном на четвертом шаге процесса (Совершенствование) за счет обсужде- 
ния результатов тестирования. Предыдущие шаги процесса имеют суще- 
ственное значение для получения заслуживающей доверия, точной, 
своевременной и исчерпывающей информации для ключевых заинтере- 
сованных лиц, но сами эти действия не приносят компании прибыли. 
Уникальность группы тестирования во многих компаниях состоит в том, 
что ее деятельность направлена на получение и обмен информацией, 
предназначенной для использования только внутри компании, т.е. груп- 
патестирования обеспечивает обратную связь с синформацией о качестве 
системы и о проекте в целом. 


| Этов равной степени верно и в случає, когда группа тестирования работаст в рамках ком- 
пании по разработке и сопровождению систем, и когда группа тестирования является частью 
компании, получающей программный продукт от внешних производителей или консалтинго- 
вых фирм. Однако в последнем случае ценность тестирования состоит практически исключи- 
тельно в снижении рисков и обеспечении информацией о проекте (пп. 3 и 4). 


Часть [. Планирование 


Поскольку процесс тестирования происходит в рамках проекта разра- 
ботки, сопровождения или поставки, процесс тестирования встраивается 
в общий контекст проекта. Но это более органичная и подвижная опера- 
ция в отличие, скажем, от включения некоторого устройства в штепсель- 
ную розетку. Наличие процесса тестирования в жизненном цикле системы 
изменяет жизненный цикл системы, а также проекты, которые следуют та- 
кому жизненному циклу. Процесс тестирования влияет сам и подвергается 
ответному влиянию со стороны проекта и системы, которые разрабатыва- 
ются или сопровождаются в рамках проекта. Проектная группа использует 
информацию, полученную в ходе тестирования, в целях корректировки 
проекта и системы. Персонал компании отвечает за выполнение проекта, 
и некоторые из этих людей отвечают за процесс тестирования. Руково- 
дство определяет правила, оказывающие влияние на то, как группа тести- 
рования взаимодействует с другими участниками проекта. 


Процесс тестирования 


На рис. 1.1 графически представлен процесс тестирования, но, по моему 
мнению, как показано в описании Процесса 1, более полезным представ- 
лением является список контрольных вопросов. Во многих проектах тес- 
тирования, в которых мне довелось работать, допускались значительные 
наложения и итерации в этом процессе. Не во всяком проекте тестирова- 
ния есть каждый этап или подэтап. Однако этот общий процесс можно 
подстроить под конкретный проект. Рассматриваемая контрольная таб- 
лица процесса должна предоставить подходящую точку отсчета в случае, 
если планируется составить перечень настраиваемых процессов. 

Если в одном проекте на различных фазах тестирования работают раз- 
ные группы (что является типичным для больших проектов), можно рас- 
сматривать несколько вариантов процесса в ходе проекта на различных 
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Процесс 1. Процесс тестирования 


№ этапа Этап 3 Выполнено? 
1. Планирование: понимание места тестирования. а 
1А . Определить функциональный (система, проект и процесс) по 
и организационный контексты, в рамках которых выполняет- 
ся тестирование. 
1.В Определить и расставить приоритеты рисков качества системы, О 


достичь консенсуса заинтересованных сторон проекта относи- 
тельно возможностей тестирования по смягчению этих рисков. 


1С Оценить временные, ресурсные и финансовые затраты, необ- О 
ходимые для выполнения тестирования и согласованные с 


пунктом 1.В, получить поддержку оценки у руководства. 


1р Запланировать задачи, зависимости и состав участников, кото- О 
рые необходимы для смягчения рисков качества системы, и по- 
лучить поддержку планау заинтересованных сторон проекта. 


2. Подготовка: сбор людей и подготовка тестов. О 


2.А Создать команду специалистов-тестировщиков, обладающих О 
соответствующими знаниями, навыками, отношением к делу 
и мотивацией, посредством поиска персонала и его обучения. 


2.В Спроектировать, разработать, получить и верифицировать О 
систему тестов, которую группа тестирования будет использо- 
вать для оценки качества системы, предназначенной для тес- 


тирования. 

3. Проведение: выполнение тестов и сбор результатов. а 
ЗА Получить и установить тестовую версию, состоящую из всех О 
или нескольких компонентов системы, предназначенной для 

тестирования. 

3.В Определить, отслеживать и управлять комплектом тестов, а 
с помощью которого планируется проверять каждую из тесто- 
вых версий. 

4. Совершенствование: предоставление информации о проекте О 
и его улучшение. і ? 

4А Документировать ошибки, обнаруженные в ходе выполнения Е 
тестов. Е 

4.В Обсудить результаты тестирования с ключевыми заинтересо- п 
ванньми лицами. 

4.С Управлять изменениями и уточнить процесс тестирования. а 


уровнях формализации. Например, при разработке одной системы для 
массового рынка группа разработки проводила неформальное модульное 
икомпонентное тестирование, группа маркетинга следила за ходом альфа- 
и бета-тестирования, а группа тестирования под моим руководством про- 
водила формальное комплексное и системное тестирование. Еще пример: 
мы работали в проекте по разработке системы для внутреннего примене- 
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ния в большом финансовом учреждении. Разработчики проводили фор- 
мальное компонентное тестирование, группа тестирования выполняла. 
формальное комплексное и системное тестирование, бизнес-аналитики 
и пользователи отвечали за неформальные приемо-сдаточные испытания, 
а сетевые операции подвергались пилотному тестированию. 

В этой главе мы изучим первую часть процесса — понимание контек- 
ста. Понимание контекста очень важно, особенно для тестирования, 
а именно для предоставления услуг и своевременного информирования 


Глава 1. Панорамный обзор 11 


участников проекта. Работа тестировщиков должна соответствовать бо- 
лее широкому контексту: проекту и проектным процессам до мельчайших 
подробностей. Если мы хотим завоевать доверие и иметь перспективы на 
будущее в компании, то должны быть компетентными тестировщиками, 
которые знают, как сделать все возможное для компании, на которую мы 
работаем. 

Примером того, что невозможно управлять ситуацией, не зная контек- 
ста, являются последние дни генерала армии США Армстронга Кастера. 
Посмертную славу принесла Кастеру в основном его роль в войне между 
Соединенными Штатами и индейцами в конце ХІХ века. Его лебединой 
песней в этот печальный период американской истории стало участие 
в битве при реке Литтл-Бигхорн (Ваше ої 11‹0е Вів Ногп), когда он был 
уверен, что преследует небольшой отряд индейцев Сиу. На самом деле он 
шел по следу большого войска Сиу под командованием Сидящего Быка и 
Неистового Коня. Кроме того, к большому огорчению Кастера, Сиу со- 
брались на общий совет, где решался вопрос о противостоянии продол- 
жающимся попыткам Соединенных Штатов насильственно отправить их 
в резервации. Нетрудно понять, что тема (контекст) совета уже соответ- 
ствующим образом настроила его участников против непрошенных гос- 
тей. Кастер и 264 его подчиненных были убиты в последовавшем сраже- 
нии, к которому их принудили индейцы, полностью окружив на холме. 
Ошибка в выборе места, ошибка во времени, ошибка в выборе цели, 
ошибка в подборе людей. Незнание ситуации ведет к неверным выводам, 
а неверные выводы могут быть очень опасны . 


Понимание функционального 
и организационного контекста 


Некоторые тестировщики и тест-менеджеры уже назначены на свои 
должности, когда организуется компания. Они начинают с того, что оп- 
ределяют организационный и функциональный контекст тестирования с 
нуля. Однако многие специалисты-тестировщики присоединяются к уже 
существующей компании или подразделению либо для организации ново- 
го процесса тестирования, либо для работы в существующем процессе. 
Помимо праздных дискуссий о лучшем организационном и функциональ- 
ном контексте, наиболее приближенным к практике вопросом является 
следующий: каким образом организационный и функциональный кон- 
текст для тестирования и тестировщики становятся такими, какими они 
должны быть? Контекст тестирования обычно существует недолго, по- 


1 Битва при Литтл-Бигхорн — не единственный эпизод неустрашимости Кастера. В битве 


при Геттисберге он возглавил кавалерийское подразделение против войск Конфедерации: 
его лошадь была убита, а сам он по счастливой случайности едва избежал смерти. Смелость 
всегда помогала Кастеру, который уже был (самым молодым на тот момент) генералом ар- 
мии США. Битва при Литтл-Бигхорн стала последним и, вероятно, наиболее опрометчивым 
деянием в его жизни, полной риска. Эта история преподносит еще один урок 
профессионалам-тестировщикам: рано или поздно привычка к большому риску приводит к 
большим потерям. Обудивительном характере и жизни генерала Кастера можно прочитать 
в биографической книге Джеффри Верта "Кастер". . 
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этому хороший тестировщик или тест-менеджер должен понимать его и 
уметь работать в нем. | 

Группы, отвечающие за проведение тестирования, возникают внутри 
группы разработки или сопровождения по множеству причин. Иногда 
просвещенный менеджмент понимает с самого начала значение эффек- 
тивного и качественного тестирования. В некоторых случаях заказчик, 
рынок, правовые и регулирующие требования вынуждают компанию 
принять некоторую стандартизованную форму тестирования. В других 
случаях компания, прошедшая период игры в рулетку качества, постав- 
лявшая заказчикам системы либо с минимальным тестированием силами 
программистов, либо вообще без оного, наконец получает убийственный 
опыт, когда плохая версия становится предметом судебного иска, теряет- 
ся важный заказчик, появляются плохие отзывы в прессе либо уходят 
наиболее ценные сотрудники. 

Понимание таких историй — важная часть формирования процесса 
тестирования, тщательно встроенного в проект. Чтобы увидеть причи- 
ны, сравним тестировщиков с другими участниками проекта. Что делают 
проектировщики, бизнесаналитики, программисты и другие специали- 
сты в проекте? Создают систему. Система не появится без этих людей. 
Даже если компания выберет оффшорную разработку, систему должны 
создать где-то в другом месте другие люди. Аутсорсинг не меняет способа, 
каким разработчики системы создают стоимость. Он только усложняет 
процесс и в некоторых случаях приводит к тому, что создаются более де- 
шевые или более качественные системы... или наоборот! 

Ранее были выделены четыре основных наиболее ценных типа ин- 
формации и услуг, поставляемых тестировщиками. Толковые менеджеры 
проектов могут использовать эти услуги и информацию для снижения об- 
щего риска неудачи проекта. Однако в некоторых компаниях менеджеры, 
вероятно, не видят этих преимуществ либо, по ошибке, верят, что тести- 
ровщики могут предоставить другие ценные преимущества, например, 
волшебным образом заставят исчезнуть ошибки. 

Читатель, как и я, возможно, время от времени с немалым удивлением 
обнаруживает непонимание того, что на самом деле могут тестировщики. 
Иногда бывалые тестировщики, читая книги и статьи о “правильном тес- 
тировании”, разводят руками, говоря; “Не могу поверить, что эти люди де- 
лают всю эту чушь!” По поводу понимания возможных проблемных ситуа- 
ций Джеральд Вайнберг прозорливо писал в “Тйе Зестеіз о Сопзийіпр": “Вещи 
таковы, поскольку они стали такими... В свое время были серьезные и дос- 
таточно обоснованные причины для принятия решений, которые сейчас 
кажутся нелепыми”. Высказывание Вайнберга применимо ко всем, кто 
впервые попадает в существующую сферу деятельности с намерением ока- 
зать влияние, изменить или просто понять, как она работает. 

Итак, что можно сделать в случае, если вы рассматриваете ситуацию, 
которая кажется рациональной или наоборот неразумной, чтобы напра- 
вить ваши усилия в верном направлении? Процесс 2 — это процесс иссле- 
дования контекста. 

Считаю, что этапы этого процесса идут параллельно и что каждый 
этап обычно нужно проходить несколько раз. Кроме того, полагаю, что 
у меня острый, восприимчивый ум. Мне нравится, когда ситуация в том 
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виде, как она представляется моим коллегам, становится ясной мне за два- 
три дня. Я стараюсь не высказывать своего мнения как можно дольше, 
пока я впитьваю новую информацию о том, как вещи стали такими, как 
они есть, и что люди думают о том, что я могу сделать в зтой ситуации. 


Процесс 2. Процесс исследования контекста 


№ этапа 


Этап 


Выполнено? 


1. 


Понять процессы жизненного цикла, применяемые в вашей 
компании для разработки, сопровождения или поставки сис- 
темы, включая любые планируемые или осуществляемые ини- 
циативы по совершенствованию процессов. 


Изучить всю документацию, относящуюся к тестированию 

и качеству, данные, метрики и измерения, в том числе планы 
тестирования, базы обнаруженных дефектов, данные об 
ошибках, найденных при эксплуатации, системы тестов и т.п. 
Понять, кто разработал все эти артефакты, почему они это 
сделали, почему они это сделали таким образом и что привело 
к таким решениям и таким результатам в компании. 


Обсудить с другими участниками проекта, в каких действиях 
тестирования они участвуют и что они собираются делать 
дальше с учетом того, что вы тоже участвуете в работе группы 
тестирования. 


Определить заинтересованных лиц своего уровня в процессе 
тестирования. Провести с ними переговоры для понимания 
взаимоотношений с теми, кто сейчас проводит тестирование, 
их ожиданий от процесса тестирования, предыдущих разоча- 
рований от процесса тестирования, конфликтов с теми, кто 
участвует в тестировании и т.п. 


Уточнить с непосредственными руководителями и старшими 
менеджерами их ожидания от процесса тестирования и от ва- 
шего участия в тестировании и в оценке качества. 


в "ЛЕЕЕ 5о/їшате Епріпеєтіпр Зіатаатаз СоЦесйот: 1997 Енот”, Ѕ‹апдага 610. 


г 


те минологий по ‘программированию (ТЕЕЕ 5 паха Сіозѕагу об `боймаге. 
-Епріпеє ЕТ а сие оценка чества (ОА) 


См. глоссарий, определяющий эти и другие стандартные термины по программированию 
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Присоединение к любой из существующих групп людей: клубу, религи- 
озной конфессии или компании — это исключительно социальный акт. 
Личность оказывает влияние на то, каким образом люди социализируют- 
ся. Некоторые люди используют в качестве метода предприимчивость. 
Вероятно, мой процесс слишком осторожный, чтобы его рассматривали 
смельчаки. В прошлом я был предприимчивее, но большая часть моих по- 
пыток проявить бесстрашие оказалась неудачной. Чем внимательнее 
я слушаю, тем лучше я делаю. На этой ноте приступим к первой части 
учебного примера — проекта “Суматра”. 


Представление проекта “Суматра” и группы 
тестирования приложения $реейуйгіќег 


Джамал Браун — менеджер группы комплексного и системного тестирова- 
ния компании 5оймаге Саѓегегіа. Зоймаге Саѓеѓегіа представляет нарынке 
интегрированный пакет офисных приложений на базе међ-технологий 
(ОЁйсеАггом), состоящий из текстового процессора (З5реедуУУгігег), 
средств обработки таблиц (ЈеіСаІс), инструмента подготовки презента- 
ций (7іррузром/) и системы управления реляционными базами данных 
(Пірбпіпрбага). Группа Джамала предоставляет услуги тестирования для 
всей линии продуктов. Он отвечает за тестирование как новых, так и со- 
провождаемых версий; тестирование последних происходит как для еже- 
месячно выходящих пакетов, так и при выпуске аварийных патчей. 

Группа комплексного и системного тестирования, которой руководит 
Джамал, входит в состав отдела поддержки программных разработок. По- 
мимо тестирования, отдел предоставляет различные услуги группе сис- 
темной разработки, в частности подготовку технической документации, 
сборку версий, поддержку внутренних систем, инфраструктуры и сети, 
поддержку пользователей. Группа системной разработки отвечает за раз- 
работку и сопровождение линии продуктов ОЁНсеАгго\. Также есть от- 
дельные группы маркетинга, продаж и финансовая группа. Структура 
компании Ѕоѓмаге Саѓегегіа показана на рис. 1.2. 

2 сентября 2002 г. группа комплексного и системного тестирования 
участвовала в общем собрании сотрудников Ѕоймаге Саѓегегіа. В ходе 
обсуждения будущих планов по развитию продукта Кейт Эрнандес, ме- 
неджер продукта ЅреейуМті‹ег, объявила, что основные работы по подго- 
товке версии 3.1 с кодовым наименованием “Суматра” начнутся в ближай- 
шие недели. В Суматру, пояснила она, должны войти несколько 
инкрементных улучшений функций обработки таблиц, импорта файлов и 
колонтитулов. В качестве основной новинки в нее войдет в качестве оп- 
ции подсистема документооборота. 

Затем она представила менеджера проекта “Суматра” Дженни Кауфман, 
которая приобрела авторитет в качестве ведущего программиста в ходе раз- 
работки версии 3.0. Дженни пояснила, что, поскольку ключевым моментом 
является поставка Суматры на рынок в первом квартале 2003 года, в проекте 
будет использоваться инкрементная модель разработки. Группа программи- 
стов в ходе нескольких итераций разработает функциональное ядро (под- 
систему документооборота), а затем добавит оставшиеся функции. Версии, 
получаемые по завершении каждой из итераций, должны работать стабиль- 


| Рис. 1.2. Структура компании Зоймаге Саївівгіа 
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но, пройти тестирование и быть готовыми к поставке. Такой подход потре- 
бует более серьезных затрат на тестирование, чем в предыдущих версиях, 
выполненных по каскадной модели. Однако, утверждала она, инкремент- 
ный подход позволит компании улучшить управление как качеством, так и 
планом выпуска версий Суматры. Ранние версии, разработанные каскадным 
методом, сказала она, вели к бурному росту ограничений бюджета и графи- 
ка, что в конечном счете выливалось в выбор, по ее словам, «между немед- 
ленной поставкой разрушающего репутацию хлама и поставкой удовлетво- 
рительного для клиентов продукта с опозданием на три месяца». Она также 
пообещала не допустить, чтобы проект потонул в «позорной яме кодирова- 
ния и исправления», что уже привело кскверной версии 2.5 с плохой репута- 
цией и со всеми вытекающими последствиями в виде физической и мораль- 
ной усталости и цинизма персонала. В заключение она сказала, что целевой 
датой выпуска первой инкрементной версии является 21 октября (т.е. при- 
мерно через семь недель) и что версия будет включать в себя лишь средства 
управления иерархическим хранилищем. 


№ этапа Этап . Выполнено? 


1. Понять процессы жизненного цикла, применяемые в вашей м 
компании для разработки, сопровождения или поставки сис- | 
темы, включая любые планируемые или осуществляемые ини- 
циативы по совершенствованию процессов. 


После собрания Джамал обсудил с Дженни и Кейт некоторые детали про- 
екта. Джамал воспринял с энтузиазмом возможность раннего начала тести- 
рования и большие объемы работ по тестированию в проекте. Его, правда, 
тревожил вопрос, готово ли руководство предоставить ресурсы, необходи- 
мые для работы в рамках инкрементной модели жизненного цикла. 

“Если я правильно вас понял, — сказал он, — я должен быть готов на- 
чать тестирование 21 октября, и далее тестирование будет продолжаться 
до конца марта. В ходе работы над версией 3.0 было запланировано 6 не- 
дель на тестирование, которые, естественно, растянулись на 12 недель, 
пока все было сделано”. 

“Да, — сказала Кейт, — и, хотя тестировщики проделали огромную ра- 
боту, мы поставили продукт с очевидными проблемами в качестве. Твоя 
группа нашла около 1000 ошибок, из которых лишь 200 были исправлены. 
Кос и я до сих пор сталкиваемся с тем, что пользователи отказываются от 
той версии, — продолжала Кейт, ссылаясь на менеджера по поддержке 
пользователей Косимо Неграева. — Конечно, рекорд версии 2.5 был по- 
бит, но не намного”. 

“Хм, никогда снова не допущу этого”, — поддержала Дженни, а Джамал 
утвердительно кивнул. 


№ этапа Этап | . Выполнено? 


2 Изучить всю документацию, относящуюся к тестированию и 
качеству, данные, метрики и измерения, в том числе планы 
тестирования, базы обнаруженных дефектов, данные об 
ошибках, найденных при эксплуатации, системы тестов и т.п. 

Понять, кто разработал все эти артефакты, почему они это 
сделали, почему они это сделали таким образом и что привело 
к таким решениям и таким результатам в компании. 
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“Джамал, ты знаком со мной уже какое-то время, и тебе известно, что 
я никогда не стремилась стать менеджером проекта, — добавила Джен- 

‚— Я сказала руководству, что соглашусь на эту должность лишь при ус- 
ловии обязательного выполнения ряда требований. Одно из них — изба- 
виться от старых моделей типа “кодируй и исправляй” и каскадной 
модели. Если у тебя будут проблемы с получением нужного объема ресур- 
сов, какими бы они ни были, чтобы начать тестирование 21 октября и 
продолжать работу до конца марта, просто зайди ко мне в кабинет и ска- 
жи, что тебе нужно. Я буду решать проблемы”. 

Затем Кейт, Дженни и Джамал перешли к обсуждению модульного 
и компонентного тестирования, а также альфа- и бетатестирования. 
Дженни рассказала о своих планах поручить каждому программисту под- 
готовить автоматизированные тесты и проводить с их помощью тестиро- 
вание собственных модулей по мере их разработки в своей тестовой сре- 
де в качестве частично формализованного (зе огиза!) модульного 
тестирования. Тесты для модульного тестирования, как и код, станут 
предметом перекрестного рецензирования (реег геуіеу). Регистрация 
кода в проектном репозитории будет пронзворитнся. лишь при соблюде- 
нии следующих трех критериев: 


1. Модульные тесты пройдены без ошибок. 
2. Рецензирование кода завершено и утверждено. 
3. Рецензирование тестов завершено и утверждено. 


Подготовленные тесты становятся частью автоматизированного на- 
бора тестов для компонентного тестирования, они выполняются в каче- 
стве части автоматизированного комплекта при ночном прогоне!. 

Джамалу было по душе слышать все это, поскольку предложенный под- 
ход поможет ему решить техническую проблему: комплексное тестирова- 
ние. Он предложил Дженни решение, при котором группа тестирования 
будет участвовать в рецензировании тестов для компонентного тестиро- 
вания, поскольку тестировщики смогут потом использовать их в качестве 
основы для комплексного тестирования. Дженни высоко оценила идею 
Джамала. Они вдвоем обсудили проблемы ресурсов, относящиеся кэтому 
виду тестирования, который обычно дает хорошие результаты, но может 
затягивать процесс разработки и требовать активного участия тестиров- 
щиков в тестировании на фазах разработки. Кейт рассказала Джамалу, 
что аналогично разработке предыдущих версий группа маркетинга пла- 
нирует и будет проводить как альфа», так и бета-тестирование. Альфа- 
тестирование начнется, как только будет готова первая интегральная 
сборка с полной реализацией первой итерации наращивания функцио- 
нальности, прошедшей компонентное тестирование. Альфа-тестирова- 
ние предполагает поставку продукта внутри компании, в том числе в про- 


1 Это не так уж сложно сделать. За дополнительной информацией можно обратиться к 
статье Рекса Блэка (Вех Віаск) и Грега Кубачковски (Стер КиђасгкомѕКі) “Мёзют Маде 
Роз, впервые опубликованной в журнале “ЗоЙшат Тейпе апі Фиаїйу Епетееппг”, 

УМоіите 4, Іѕѕџе 4 (|мі /Ацв 2002) и доступной в настоящее время на мум. Аа сот 
и ууу тех асксопзитр-сот, 
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ектной команде Суматры, а также некоторым тщательно отобранным 
партнерам по бизнесу. 

Бета-тестирование начнется после завершения первого цикла систем- 
ного тестирования первой итерации наращивания функциональности, 
т.е. при удовлетворительных результатах тестирования. Кейт сказала 
Джамалу, что она должна работать в тесном контакте с ним, чтобы убе- 
диться, что наиболее существенные для бета-тестирования свойства и 
функции тщательно протестированы в ходе первого цикла системного 
тестирования. Джамал ответил, что это отличная мысль, но Дженни так- 
же должна проверить, что соответствующие свойства продукта уже реа- 
лизованы группой разработки и подвергались тщательному компонент- 
ному тестированию. Дженни согласилась, добавив, что она понимает, что 
Джамал не может повысить качество некачественного продукта за счет 
тестирования. 


№этапа Этап Выполнено? 


8. Обсудить с другими участниками проекта, в каких действиях И 
тестирования они участвуют и что они собираются делать с | 


учетом того, что вы тоже участвуете в работе группы тестиро- 
вания. 


К этому моменту Джамал полностью представлял контекст своей рабо- 
ты, по крайней мере, так, как видят его Кейт и Дженни. Поскольку они яв- 
ляются ключевыми заинтересованными лицами, крайне важно, чтобы 
они понимали, каким образом группа Джамала будет встроена в проект. 
Однако Джамалу известно, что понимание текущей ситуации является не- 
прерывным процессом. Лучшие тестировщики не прекращают следить за 
внешними проявлениями того, что означает непонимание или несогла- 
сие коллег с тем, что делает группа тестирования. Уместность тех или 
иных действий существенна для доверия, а доверие в свою очередь, как 
вам скажет любой газетчик, имеет огромное значение для тех, кто постав- 
ляет жизненно важную информацию. Хотя Джамал работал в компаний 
уже больше года, он планировал встречи с руководством и коллегами для 


‘уточнения их ожиданий и собирался повторять такие встречи в ходе все- 


го проекта. 


№этапа Этап Зыполнено? 


4. Определить заинтересованных лиц своего уровня в процессе | 
тестирования. Провести с ними переговоры для понимания 
состояния взаимоотношений с теми, кто сейчас проводит тес- 
тирование, их ожиданий от процесса тестирования, предыду- 
щих разочарований от процесса тестирования и конфликтов 
стеми, кто участвует в тестировании и т.п. 


5. Уточнить с непосредственными руководителями и старшими 
менеджерами их ожидания от процесса тестирования и от ва- 
шего участия в тестировании и в оценке качества. 
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Место тестирования в моделях жизненного цикла 
разработки 


Ранее упоминались две методологии разработки: каскадная модель 
(и ее вариация — У-модель) и инкрементная модель. В рассматриваемом 
примере Дженни предлагает инкрементную модель как наиболее подхо- 
дящий выбор для проекта 5реедуУУгігег. 

Обсуждение выбора наилучшей модели для данного проекта находит- 
ся за рамками этой книги. Каждая из моделей жизненного цикла спроек- 
тирована для наиболее успешной работы с проектными рисками опреде- 
ленного вида. Кроме того, модели жизненного цикла, как правило, 
связывают с определенными видами разработки, сопровождения и по- 
ставки систем. Например, на своем ууеБ-сайте компания Кайопа] продви- 
гает процесс разработки, известный как Кайопа! Опійеай Ргосез5, в качест- 


Обзор моделей жизненных циклов можно найти в главе 2 книги Роджера Прессмана 
(Ворег Ргеѕзѕтап) "5о/їоате Епріпеетіпр, Еоитіћ Е@нот” и в главе 9 книги Стефана Кана (ЗерБеп 
Кап) “Мес; апа МодеБ т Зойиате Оцайу Епріпеетіпр, 5есопа Енот”. 
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Рис. 1.3. \-модель жизненного цикла каскадной модели разработки системы 


ве наиболее подходящего для проектов разработки с использованием 
объектно-ориентированных технологий. 

Как и предусматривает слово “модель”, описываемые жизненные циклы 
являются абстракцией и упрощенным представлением определенного круга 
людей о том, как делаются успешные проекты. Аналогичным образом я опи- 
сываю в этой книге процессы, которые моделируют мои представления о 
том, как необходимо вести успешные подпроекты тестирования. 

Сколько всего существует моделей жизненного цикла? Поверхност- 
ный поиск в Интернете выдает ссылки на десятки различных методоло- 
гий для объектно-ориентированного программирования. Некоторые из 
этих методологий говорят об особых жизненных циклах, другие более 
легковесны, с менее строгими ограничениями на порядок фаз и сами 
фазы, с большим акцентом на людей, нежели на процессы . 


1 на мии. сетаз-НиКз.огр представлен целый набор ссылок, связанных с объектно-ориен- 
тированным программированием, включая ссылки на методологии. Также существуют раз- 
личные меб-сайты, описывающие легкие технологии, рассказывающие о так называемых 
быстрых методах, в частности об экстремальном программировании (Ехігете Ргортагат- 
іп). См., например, уму шагашо\щег.сот/агис!е5/пеуМеюдоюзу.Вит]. 
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Насколько точно эти модели описывают то, что реально имеет место? 
Приведем высказывание, на авторство которого претендуют и Э.Деминг, 
и Джордж Бокс (Сеогре Вох): “Все модели неверны, некоторые модели 
полезны”. До определенной степени распространение разных моделей 
указывает на различие взглядов и полемику, существующие вокруг спосо- 
бов создания систем. Чем более популярны жизненный цикл и методоло- 
гия, тем больший огонь критики они на себя вызывают. Например, неко- 
торые специалисты писали, насколько ужасна У-модель. Тем не менее она 
по-прежнему широко применяется. Это не просто результат инерционно- 
сти или лености мышления. Вариантом, интуитивно понятным, широко 
известным и более предпочтительным, нежели хаос, часто является У-мо- 
дель. Однако любая методология и любой жизненный цикл могут подхо- 
дить для конкретно взятой ситуации или нет. В одном случае происходит 
одно, в другом — другое. Поскольку каждый проект по-своему уникален, 
менеджеры и другие участники должны подстраивать выбранный жиз- 
ненный цикл под свои, специфические потребности. 

Эти модели являются не только приближением того, что должно быть, 
но и того, что реально происходит, когда их пытаются применять в проек- 
тах. Иногда подгонка модели хорошо продумана, иногда не столь точна 
иаккуратна. Я был свидетелем проектов, в которых поначалу применялся 
тот или иной жизненный цикл, но затем они скатывались в яму кодирова- 
ния и правки, причем наиболее часто на фазе тестирования, когда проект 
выходил за пределы исходного графика и бюджета. 


‚высоким урови ем 


Что означает для тестировщика распространение различных и несо- 
вершенных моделей? Есть сильный соблазн проигнорировать эту “вави- 
лонскую башню” методологий как бессмысленное отвлечение внимания. 
Это особенно верно, поскольку некоторые из этих моделей (например, 
У-модель) разработаны специально для тестирования, другие только учи- 
тывают его, а третьи вовсе не принимают его во внимание. К примеру, 
экстремальное программирование много внимания уделяет надежному 
модульному и компонентному тестированию силами программистов, но 
практически не затрагивает комплексное и системное тестирование. По- 
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Проектирование 
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Рис. 1.4. Жизненный цикл инкрементной разработки системы 
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скольку различные фазы тестирования ориентированы на поиск различ- 
ных категорий дефектов, тестировщики вынуждены заполнять пробелы, 
если они работают над проектом, который следует модели экстремально- 
го программирования. 

Существуют три важных для тестировщиков обстоятельства, связан- 
ных с этой темой. Во-первых, в рамках контекста проекта необходимо со- 
хранять гибкость при встраивании тестирования в выбранный жизнен- 
ный цикл или методологию. Нужно понять, каким образом адаптировать 
и предоставить значимые услуги и информацию, что бы ни происходило. 
Также необходимо строить гибкие планы на случай, если выбранная ме- 
тодология начнет деградировать до безумия “кодирования и исправле- 
ния”, чтобы продолжать поставлять значимые услуги и информацию 
даже в условиях полного хаоса. На самом деле, в этой книге я описываю 
идеи, которые могут оказаться полезными независимо от того, работаете 
ли вы в строго следующем процессам проекте или внутри циклона с бес- 
порядочно меняющимся кодом. 

Во-вторых, встраивание процесса тестирования в объемлющий 
жизненный цикл влечет за собой необходимость понимания последо- 
вательности и взаимозависимости действий. Под выстраиванием по- 
следовательности действий понимается, насколько отдельные части 
процесса тестирования вписываются в жизненный цикл системы втер- 
минах временной протяженности. В частности, У-модель устроена 
таким образом, что проектирование и разработка системы тестов 
должны начинаться как можно раньше. Тестировщики, работающие 
по У-модели, разрабатывают тестовые сценарии, тестовые данные, 
тестовые скрипты, инструменты тестирования, тестовую среду и дру- 
гие компоненты системы тестов во время фаз сбора требований, про- 
ектирования архитектуры и реализации кода. Раннее начало действий 
по проектированию и разработке системы тестов нацелено на своевре- 
-менное проведение приемо-сдаточных испытаний и системного тести- 
рования, включая частные задачи проектирования и разработки для 
фаз комплексного и компонентного тестирования. Не все модели жиз- 
ненных циклов столь явно описывают последовательность действий, 
однако в каждом проекте необходимо выбрать правильное время для 
начала важнейших процессов тестирования. На выбор времени оказы- 
вают влияние взаимозависимости. Например, если мы разрабатываем 
тесты на основе требований, мы не можем начать это делать, покау нас 
нет требований. 

В-третьих, в рамках более широкого сообщества системных о 
чиков тестировщики обязаны заботиться о росте своего участия в непре- 
кращающихся дискуссиях о жизненных циклах и методологиях. Процес- 
сы весьма значимы, а тестирование — важная часть процесса системной 
разработки. Вопросы выстраивания последовательности и взаимозави- 
симостей действий оказывают серьезное виляние на успех подпроектов 
тестирования. Мы должны помочь людям, которые говорят о процессах, 
понять важнейшие процессы тестирования и то, как они соотносятся с 
другими активностями разработки. Еще одна задача этой книги — стать 
частью этой дискуссии. 
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Организация тестировщиков и тестирования 


Помимо непрекращающихся дебатов по поводу методологий и функцио- 
нального контекста тестирования в рамках различных моделей жизнен- 
ного цикла, не утихают споры вокруг проблем, связанных с организацией 
тестировщиков и тестирования. Тестирование может быть организовано 
в рамках группы разработки, внутри проекта, в виде поставок услуг проек- 
ту независимой группой тестировщиков, некоторым образом внутри ком- 
пании, приобретающей систему, или в виде комбинации описанных под- 
ходов. Группа тестирования, если она отделена от группы разработки, 
может подчиняться менеджеру разработки, менеджеру проекта, какому- 
либо из линейных менеджеров, исполнительному менеджеру либо одно- 
му из высших руководителей. 

Я предпочитаю руководить отдельной группой тестирования или ра- 
ботать в такой группе. Мне нравятся независимые группы тестирования, 
которые не готовят отчеты для менеджеров, в качестве стимула выбираю- 
щих счетчик найденных дефектов и тщательную проверку качества. Од- 
нако мне также нравятся группы тестирования, которые встроены в про- 
ектную команду с целью включения в работу над проектом с его ранних 
фаз. Я люблю наблюдать за такими независимыми, но интегрированны- 
ми группами тестирования, сосредоточившими усилия на наиболее от- 
ветственных фазах тестирования — комплексном и системном тестирова- 
нии — таким образом, что они дополняют модульное и компонентное 
тестирование, которые в свою очередь отдаются на откуп группе разра- 
ботчиков. Я также приветствую формальное и неформальное тестирова- 
ние, выполняемое пользователями или замещающими их лицами, в част- 
ности альфа- и бета-тестирование для продуктов массового спроса и 
приемо-сдаточные испытания в мире технологий и систем управления 
информацией. Если услуги тестирования требуются сразу нескольким 
проектам, лучше, если единая группа тестирования будет предоставлять 
такие услуги всем проектам . Почему я рекомендую этот подход? 

Для оптимального поиска и устранения дефектов необходимо под- 
вергнуть систему структурному и функциональному тестированию, а так- 
же тестированию в реальных условиях. Эти три стиля тестирования по- 
зволяют обнаружить различные типы ошибок й предоставить различный 
материал для отладки. Например, ошибки, связанные с неинициализиро- 
ванным указателем, могут иметь различные проявления при проведении 
функционального тестирования, часто ставя в тупик и тестировщика, 


‚и программиста. Однако существуют простые методы структурного тес- 


тирования (например, препроцессор пі в ОМІХ /С), позволяющие обна- 
ружить переменные, используемые до их инициализации. 

В настоящее время структурное тестирование базируется в основном 
на навыках программирования и другой технической подготовке, а функ- 
циональное тестирование часто требует дополнительно специализиро- 
ванных навыков тестирования и знания предметной области (см. главы 8 


‚ и 9). Примерами видов тестирования, требующих специализированных 


См. главу 9 моей книги “Мапазта іће Теѕітр Ргосезз, Зесопа Еайіоп". 
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навыков, являются тестирование безопасности и производительности, 
в которых обычный программист не является специалистом. Что же каса- 
ется примера предметной области, то один из моих заказчиков работает 
над системой геологического моделирования для поиска и разработки 
месторождений нефти. Чтобы тестировать функциональность и последо- 
вательность действий, необходимо быть геологом, геофизиком или спе- 
циалистом из смежной области, но не программистом. 

Я заметил, что проекты, в которых мне приходится участвовать, идут 
более гладко, если программисты проводят модульное и компонентное 
тестирование своего кода. С развитием таких подходов, как экстремальное 
программирование, такая позиция становится менее спорной. Выполне- 
ние модульных и компонентных тестов требует и навыков структурного 
тестирования, и умения программировать. Логично, что люди, ответст- 
венные за выполнение таких тестов, являются членами команды програм- 
мистов. Однако многие программисты (и я втом числе) испытывают труд- 
ности при тестировании собственного кода. Удачной практикой является 
внедрение процесса разработки, предусматривающего модульное тестиро- 
вание, в ходе которого программисты ищут ошибки в своем коде, и компо- 
нентное тестирование, когда программисты проверяют код, написанный 
коллегами. (Иногда такой способ называется “обменом кода”.) Вариации 
этого подхода используют идеи парного программирования и экспертной 
оценки автоматизированных тестовых заглушек компонентов или тесто- 
вых драйверов. 

Однако, поскольку для функционального тестирования требуются 
специальные навыки, объединять людей, на которых возложены эти обя- 
занности, в независимую группу тестирования имеет смысл, как мини- 
мум, по трем причинам. Во-первых, когда есть двое и более примерно оди- 
наково подготовленных людей, это повышает синергетику группы. 
Например, тестировщики могут рецензировать тестовые сценарии, ре- 


Более подробно о структурном тестировании см. Брайан Марик (Вгіап МапсК) “Сай оў 
Зойшате Тезіітв", Роберт Биндер (Корегі Віпдег) “Тёзёте Обуєсі-Опієпіга 5о/їшате" и Борис Бейзер 
(Вогіѕ Веігег) “ЗоЛшате Тезйтр Тестідиез". 
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зультаты тестирования, отчеты об ошибках, подготовленные коллегами. 
Во-вторых, объединение в группу тестирования способствует укрепле- 
нию боевого духа, что важно для качественного тестирования, поскольку 
во многих случаях приходится сообщать плохие новости. В-третьих, на- 
личие группы тестирования дает возможность для специализации, совер- 
шенствования навыков и карьерного роста. Взаимодействие всех этих 
факторов способствует повышению производительности тестировщи- 
ков и укреплению доверия к результатам, получаемым группой тестиро- 
вания. 

Группа тестирования, работающая одновременно в нескольких про- 
ектах, предоставляет еще более широкие возможности для специализа- 
ции и карьерного роста. Я работал в одной группе тестирования, постав- 
лявшей услуги тестирования разнообразным проектам по разработке 
систем для персональных компьютеров. В нашей группе были отдель- 
ные подразделения, специализировавшиеся на тестировании сетей, 
клиентов УЛпдомз, серверов Міпдом5, на тестировании ОМІХ-систем, 
тестировании приложений и т.п. В этих подразделениях работали силь- 
ные специалисты-тестировщики, как того требовали наши проекты. 

Я отдаю предпочтение группам тестирования, возглавляемым компе- 
тентным, опытным тестировщиком, обладающим навыками управления. 
В этом случае тест-менеджер выступает как в роли технического лидера, 
так и в роли руководителя группы. Надо сказать, что лучшие менеджеры 
групп разработки в моей практике становились и хорошими программи- 
стами, и хорошими менеджерами. Достигнув определенного уровня в ие- 
рархии руководства, менеджеру действительно нет необходимости вни- 
кать в детали работы подчиненных. Однако, если менеджер осуществляет 
непосредственное руководство сотрудниками, которые собственно раз- 
рабатывают или тестируют систему, комбинация технической квалифи- 
кации и умения руководить в одном лице срабатывает великолепно. 

Руководство группой тестирования является определяющим, посколь- 
ку функциональное тестирование — это сложный подпроект в рамках всего 
проекта в том случае, если он осуществляется независимой группой тести- 
рования. Между проектом и подпроектом тестирования существует мно- 
жество взаимосвязей и взаимозависимостей. Кроме того, постоянные из- 
менения в проекте должны находить как очевидные, так и едва заметные 
отражения в организации тестирования. Тест-менеджер выявляет эти за- 
висимости и управляет изменениями в них. Он также должен обладать хо- 
рошими навыками управления персоналом, в частности для подбора лю- 
дей и расширения группы тестирования. Наконец, тест-менеджер должен 
быть защитником интересов группы тестирования и уметь договариваться 
по насущным вопросам, связанным с тестированием. 
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Независимая группа тестирования должна получить необходимую 
часть ресурсов проекта. Независимая группа тестирования должна уметь 
беспристрастно информировать о полученных результатах, как хоро- 
ших, таки плохих. Таким образом, структура управления не должна созда- 
ватьутестировщиков неправильных стимулов в их работе. Представим, к 
примеру, вполне обычную ситуацию: менеджер разработки получает пре- 
мию в случае поставки системы с определенным набором функций в срок 
и в рамках бюджета. Что произойдет, если тест-менеджер сообщит менед- 
жеру разработки, что при данных свойствах будущей системы, парамет- 
рах бюджета и сроках в системе останется много ошибок? Это вполне 
обычная ситуация, порождающая напряженность в отношениях тест- 
менеджера и менеджера разработки. Что будет, если руководитель менед- 
жера разработки обратится к тест-менеджеру с просьбой оценить качест- 
во системы и дать прогноз, когда ее качество будет пригодно для постав- 
ки? Тест-менеджер поставлен перед нежелательным конфликтом 
интересов. Он может либо сообщить правду и указать на ошибки руково- 
дителя, либо приукрасить ситуацию и существенно снизить ценность 
группы тестирования для компании. 

Я наслышан от коллег и от участников моего семинара по управлению 
тестированием о том, что компании могут разрешить эти политические 
проблемы посредством сочетания организационной структуры компании 
и интересов каждого из участников проекта с поставкой продукта, в кото- 
ром соблюдается баланс свойств, сроков, бюджета и качества. В тех компа- 
ниях, в которых принята система вознаграждения менеджеров проектов и 
менеджеров разработки исключительно на основе сроков и бюджета, по- 
зиция тест-менеджера в организационной структуре на одном уровне с ме- 
неджером проекта и/или менеджером разработки может восстановить ба- 
ланс между качеством, сроками, бюджетом и функциональностью. 

Теперь вам известны мои предпочтения, однако здесь существует мно- 
жество вариантов. Один изудачных вариантов показан в нащем примере, 
Тест-менеджер Джамал Браун целиком отвечает за поведенческое тести- 
рование различных продуктов О сеАтгоу на фазах комплексного и сис- 
темного тестирования. Джамал отчитывается перед менеджером группы 
поддержки разработок Джоном Албертсоном, который занимает в струк- 
туре компании позицию на одном уровне с Гарольдом Джоунзом, менед- 
жером системных разработок. Они оба подчиняются Раджешу Гупте, ге- 
неральному директору компании. Джамал занимает то же положение в 
компании, что и Дженни, его коллега, менеджер разработки. 
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При другом способе организации работ в случае тестирования не- 
скольких проектов одновременно в группе, предоставляющей услуги 
тестирования, выделяется по одному старшему тестировщику, высту- 
пающему в роли эксперта по предметной области, на каждый проект от 
начала до конца, либо по тестировщику-консультанту, отвечающему за 
все задачи тестирования для данной системы. Другие сотрудники груп-` 
пы тестирования сосредотачиваются на предоставлении тестовых ус- 
луг в нескольких проектах одновременно. Тестировщик-консультант, 
который является специалистом как в структурном, так в поведенче- 
ском тестировании, выступает в роли технического эксперта по всем 
вопросам тестирования с первого дня проекта разработки системы. 
В совместной работе с программистами тестировщик-консультант со- 
действует качественному проведению модульного, компонентного и 
комплексного тестирования, подчиняется по техническим вопросам 
менеджеру разработки и отчитывается перед ним об этих активностях, 
оставаясь организационно сотрудником группы тестирования. Тест- 
менеджер решает совместно с тестировщиком-консультантом и други- 
ми тестировщиками вопросы планирования тестирования, разработ- 
ки тестов, построения тестовой среды для отдельной фазы системного 
тестирования. С началом фазы системного тестирования тестиров- 
щик-консультант возвращается в группу тестирования. В этот период 
все тестировщики являются ценными ресурсами для ведущего тести- 
ровщика и тест-менеджера, организующих системное тестирование. 
Тестировщик-консультант собрал огромный экспертный материал о 
системе, хорошо представляет ее сильные и слабые стороны и теперь 
консультирует группу тестирования. На рис. 1.5 показана структура 
группы, включая двух тестировщиков-консультантов (один работает в 
проекте А, второй - в проекте В), которые временно приписаны к со- 
ответствующим проектным группам. (Я упростил рисунок, удалив отту- 
да других возможных участников проектов разработки, не входящих в 
группы разработки и тестирования.) 

На рис. 1.2 и 1.5 показаны только две возможности из большого списка 
хорошо зарекомендовавших себя эффективных вариантов организаци- 
онного контекста, в рамках которых успешно проводится тестирование. 
Рекомендую исследовать организационную структуру различных проек- 
тов до того, как вы сделаете свой выбор. Мне довелось общаться со многи- 
ми состоявшимися тестировщиками, работавшими с самыми разнообраз- 
ными подходами на базе двух моделей, представленных мной. 

Прежде чем перейти к другой теме, хотелось бы поговорить немного 
об одном способе организации группы тестирования, который я считаю 
ошибочным. Некоторые выступают за отсутствие какой бы то ни было 
группы тестирования, считая, что тестировщики могут работать вместе с 
программистами в группах разработки. Аргументы в защиту этого типа 
организации тестирования сводятся к положительному эффекту интег- 


1 Подробное обсуждение организационных структур, в рамках которых проводится тес- 


вание, а также их преимуществ и недостатков можно найти в главе 13 книги Эдда Кита 
(Еа Кіє) “боДниате Теніпр іп фе Ве Уп”. Брайан Марик также затрагивает организационную 
структуру и другие вопросы контекста тестирования в статье “Сіаѕѕіс ТезНпя М1ыаКе5". Ее 
можно найти на сайте ууу.еѕіпр.сот\утійпрз.Һопі. 
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рирования тестировщиков в группу разработки, что уравнивает в правах 
тестирование и разработку, позволяет отыскать больше ошибок и помо- 
гает осуществлению отладки. 

Как я уже отмечал ранее, так могут быть организованы некоторые 
виды тестирования. Мне нравится, если структурное тестирование орга- 
низовано как часть модульного и компонентного тестирования внутри 
группы разработки непосредственно с начала кодирования. Однако я 
против неявного предположения, что тестировщики, которые подчиня- 
ются менеджерам разработки, обязательно превосходят тестировщиков, 
подчиняющихся независимым тест-менеджерам, в показателях эффек- 
тивности и качества тестирования, отчетов об ошибках, в проценте ис- 
правленных ошибок и в длительности цикла существования ошибки. 
В последующих главах я дам соответствующие объяснения. 

Не могу не отметить, что вакансии тестировщиков в группах разра- 
ботки и сопровождения часто предполагают роли младших программи- 
стов. Младшему персоналу обычно меньше доверяют, нежели более 
опытным сотрудникам. Ранее я писал, что основная ценность тестиро- 
вания в своевременном информировании. Таким образом, тестировщи- 
ки выполняют свою миссию, если люди прислушиваются к ним, а обыч- 
но более внимательно я к тем людям, кому больше 
доверяют. 

Идея назначения тестировщиками младших программистов, разбро- 
санных по компании, имеет, по крайней мере, два отрицательных послед- 
ствия для процесса тестирования. Первое касается квалификации: со- 
трудники, назначенные на роли тестировщиков, вероятно, обладают 
хорошими техническими навыками, но вряд ли им много известно о пред- 
метной области и о тестировании. Ктому же, поскольку карьерные планы 
временных тестировщиков связаны с ролями программистов, они, по 
всей вероятности, будут стремиться улучшить техническую подготовку и 
знания предметной области, но лишь единицы озаботятся овладением на- 
выками тестирования. В области тестирования они будут слабы, хотя уст- 
ранение именно этих слабостей наиболее важно для их текущих обязан- 
ностей. Например, если перед младшими программистами встанет 
выбор между обучением структурному и поведенческому тестированию 
или обучением свежим методологиям программирования, вероятнее все- 
го, они сделают выбор в пользу последнего, заботясь о своих долгосроч- 
ных карьерных устремлениях. Такие рациональные решения младших 
программистов снижают вероятность качественного и эффективного 
проведения тестирования. 

Второе отрицательное последствие связано с вопросами управления. 
В тех случаях, когда старшие или высшие руководители принимали реше- 
ние ликвидировать независимую группу тестирования и ввести тестиров- 
щиков в группы разработки, такие решения, как правило, были связаны с 
неудачными проектными планами. Такие способы реорганизации груп- 
пы тестирования как ответ на проблемы со сроками проекта являются 
признаком невысокой зрелости компании. В этом качестве предлагаемые 
изменения представляют собой бесполезную реакцию на просчеты в 
управлений, а не рациональную попытку оптимизировать процесс тести- 
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рования. Они не позволят достичь желаемого спасительного эффекта 
для неудачного проекта. 

Некоторые люди, мнение которых я уважаю, говорили мне, что они ви- · 
дели, как подходы, связанные с включением тестировщиков в группы раз- 
работки, успешно работают. Насколько я понимаю, успех таких решений 
связан, прежде всего, с относительно небольшими и несложными проекта- 
ми разработки или сопровождения. Не сомневаюсь, что информация о по- 
ложительном опыте, полученная не из первых рук, верна, но я не могу при- 
помнить ни одного успешного проекта тестирования, выполненного 
силами только младших программистов, работающих внутри большой 
группы разработчиков. Большинство изучастников моего семинара разде- 
ляют мое мнение. Не проведя формального исследования, тестировщики 
могут только высказывать предположения, а не оперировать объективны- 
ми данными в поддержку своих выводов. Тем не менее, согласно моим не- 
научным наблюдениям, негативное влияние на успех работ тестировіцє 
ков внутри групп разработки оказывают мощные факторы. 

Выразив свое мнение по спорной теме поиска наилучшего места для 
тестирования и тестировщиков в компании, я намереваюсь отложить ее в 
сторону до конца книги. Организационная структура оказывает влияние 
на ключевые процессы, особенно на процессы, в наибольшей степени 
увязанные с контекстом, например на подготовку отчетов о результатах 
тестирования. Даже тестировщики, работающие в одиночку в качестве 
единственного ресурса тестирования в проекте, вероятно, обнаружат, 
что большинство, если не все важнейшие процессы, обсуждаемые в этой 
книге, применимы к их контексту тестирования. 


Измерения управления 


Началом любой карьеры, связанной с управлением или техническим руко- 
водством, обычно является совместная работа с менеджерами того же уров- 
ня или более высокими руководителями. Исполнители в повседневной ра- 
боте обычно контактируют со своими непосредственными начальниками, 
которые дают им прямые указания. В этом случае для непосредственного ис- 
полнителя управление имеет одно измерение: взаимодействие с непосред- 
ственным руководителем. Для старшего тестировщика или тест-менеджера, 
имеющего в качестве основной обязанности подготовку отчетов об ошиб- 
ках и результатах тестирования для рабочей группы проекта, ситуация будет 
меняться. Такое изменение помогает увидеть различные измерения управ- 
ления и их влияние на подготовку отчетов о результатах тестирования. 

Ранее были упомянуты четыре наиболее ценных результата работы 
большинства групп тестирования: 


1. Обнаружение ошибок, которые будут устранены, или даже предот- 
вращение их внесения. 


2. Обнаружение ошибок, которые не будут устранены, но о которых 
становится известно. 


1 Ввведении ккниге Рашки др. “Тйе Сара у Маитіу МодеГ приводятся комментарии к си- 
туации в компании, которая избавляется от тестирования при первых признаках серьезных 
проблем со сроками или бюджетом. 
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3. Проведение тестов, которые снижают (потенциально затратные) 
риски. 


4. Обеспечение проекта своевременной, точной и заслуживающей 
доверия информацией. 


Хотя результаты, которые ожидает получить компания от группы тес- 
тирования, могут меняться, ключевым отличием между ними является 
то, насколько сложно структурировать работы по тестированию, чтобы 
получить информацию и передать ее проектной группе таким образом, 
чтобы эта информация была бы использована с наибольшей эффективно- 
стью. Вот почему, по моему мнению, многие группы тестирования редко 
выходят за пределы первой половины пункта 1, занимаясь обнаружением 
дефектов в текущей системе. В правильном организационном, техноло- 
гическом и проектном контексте, если внедрить 12 ключевых процессов, 
представленных в этой книге, то удастся порождать информацию, позво- 
ляющую добиться максимальной отдачи от вложений в тестирование, 

Порождение информации требует преимущественно управления 
"вниз" (тапазшр шмага). Под управлением “вниз” я понимаю выполне- 
ние всех действий тестирования внутри группы тестирования. Как клю- 
чевой процесс тестирования оно вовлекает то, о чем я говорил во введе- 
нии как о преимущественно внутренних процессах. 

Но порождение информации — это не все, что требуется. Возврат вло- 
жений происходит посредством эффективного обмена полученной ин- 
формацией, причем эта информация должна быть привязана к проектно- 
му, организационному и технологическому контексту. 

‚ Эффективный обмен информацией, привязанной к соответствующе- 
му контексту, требует преимущественно управления “вниз” и “вне”: 
Управление “вверх” предполагает обмен информацией с непосредствен- 
ными руководителями, другими старшими менеджерами и высшими ру- 
ководителями. Управление “вне” включает в себя обмен информацией с 
техническими руководителями и менеджерами разработки, конфигура- 
ционного управления, управления сборкой, продаж, финансовыми ме- 
неджерами, менеджерами операций и технической поддержки, бизнес- 
аналитиками и т.д. того же уровня, что и тест-менеджер. На рис. 1.6 пока- 
зана упрощенная схема, реальные проекты значительно сложнее. Кон- 
текст вашей работы может состоять из другого множества вертикальных 
и горизонтальных связей. 

Что касается должностей ведущего тестировщика и тест-менеджера, 
то эффективность его управления “вверх” и “вне” оказывает большое 
влияние на общую оценку его работы. Иными словами, руководители и 
коллеги оценивают компетентность тест-менеджера не только по тому, 
как он получает информацию, но и (в не меньшей степени) по тому, как 
онвыбирает информацию для дальнейшей работы и как он обменивается 
этой информацией с ними. 

Управление "вверх" и “вне” ставит разнообразные проблемы перед ве- 
дущим тестировщиком и тест-менеджером. Даже опытные руководители 
разработки не всегда понимают роль и значение тестирования. В настоя- 
щее время область тестирования программ включает в себя такой объем 
знаний, что не каждый опытный тестировщик может охватить все. Это 
делает для тестировщика задачи взаимодействия еще более сложными. 
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Руководители проекта 
и топ-менеджеры 


Руководитель 
разработки 


Менеджер | 
по маркетингу 


Тестировщик 


Рис. 1.6. Обмен информацией при управлении тестированием 


Если тестирование проводится верно, возможно, наиболее важные ре- 
зультаты тестирования часто означают плохие новости для коллеги руко- 
водителей тест-менеджера. Компетентные тестировщики редко бывают 
в ситуации, когда они сообщают руководителям проекта: "Все тесты были 
выполнены в течение ночи, не обнаружено никаких значимых ошибок, 
можно поставлять продукт”. 

Проблемы управления “вне” и “вверх”, в отличие от технических про- 
блем, редко имеют простые решения. Однако здесь могут пригодиться 
полезные методики. По мере обсуждения критических процессов тести- 
рования, вкоторых выявляются проблемы управления “вне” и "вверх", бу- 
дут рассмотрены некоторые идеи решения таких проблем . 


За рамками контекста процесса тестирования 


В этой главе сначала было введено понятие процесса тестирования на са- 
мом низком уровне детализации, а затем мы определились с вопросами 
контекста, которые оказывают влияние на процесс тестирования. Сей- 
час я собираюсь перейти к другой теме, однако понимание и определение 


1 Части этого раздела впервые были опубликованы в статье “Еесйуе Тех бал 
Керог 8” в журнале "5о/їшате Тейт апа Оиаійу Епртеетту", Моїате 2, Іѕѕие 2 (Маг/Арг 
2000), доступной сейчас на сайтах муу.ѕіскутіпаз.сот и мили гехБіасксопаиійпя сот. 
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контекста — это не единовременный акт. Меняются ожидания, к проект- 
ной группе присоединяются новые заинтересованные лица, у высшего 
руководства неожиданно возникает специфический интерес к проекту, 
в середине проекта могут произойти реорганизации. Благоразумные тес- 
тировщики бдительно следят за актуальностью контекста. 

В этой главе мы уже прошли большой путь в определении контекста. 
Установление контекста тестирования нуждается в исчерпывающем об- 
суждении, поскольку процесс тестирования существует в самых разнооб- 
разных формах. Понимание контекста, в котором работают тестировщи- 
ки, и внесение коррективов в случае, если что-то не функционирует 
в нем, — очень важный первый этап для тестировщиков, поскольку это 
позволяет группе тестирования перейти от практически бесконечного 
множества задач тестирования к более приемлемому набору в границах 
выбранной функциональной и организационной схемы. Задачи тестиро- 
вания из последнего набора, вероятно, будут выполнены для создания но- 
вой стоимости. Следующие несколько глав будут посвящены разработке 
реалистичного, выполнимого плана с серьезной организационной под- 
держкой в рамках выстроенного контекста. Сначала я составляю план на 
основе представления о том, что нужно тестировать, а затем на основе 
того, что я реально могу протестировать. Каждый из этих дополняющих 
друг друга процессов планирования, а также все последующие процессы 
для успешного выполнения должны без помех встраиваться в контекст 
тестирования. 


ГЛАВА2 = | 


Основа успеха: 
анализ рисков качества 


функциональном и организационном контексте, выстроенном для 

процесса тестирования, можно выполнить огромное число тестов. 
Для любой по-настоящему сложной системы число тестов, которые мож- 
но было бы разработать и выполнить, потребовало бы человеко-годы, 
если не человеко-века. Так или иначе, необходимо сосредоточить внима- 
ние на тех тестовых условиях, которые нельзя не проверить, и не прини- 
мать к рассмотрению огромное количество несущественных условий, ко- 
торые мы также могли бы проверять. Что же отличает области системы, 
которые мы могли бы тестировать, от тех областей, которые мы должны 
тестировать? Ответ — качество! 

В предыдущей главе говорилось, что процесс тестирования приносит 
дивиденды благодаря предоставлению услуг и информации о рисках, уг- 
рожающих качеству системы. Чтобы предоставляемые услуги и информа- 
ция имели ценность, необходимо, чтобы тестирование было нацелено на 
проверку функций, которые значимы для заказчиков и пользователей, 
функций, которые оказывают влияние на мнение пользователя о работе 
с системой. Тестирование несущественных частей системы вызывает 
ложную уверенность в правильной работе системы в случае успешного 
прохождения тестов, расходует впустую время разработчиков и тести- 
ровщиков на решение элементарных проблем в случае обнаружения оши- 
бок. В то же время серьезные дефекты в непокрытых тестами областях 
системы остаются незамеченными, всплывая после выпуска версии пе- 
ред пользователями системы. Чтобы провести тестирование, направлен- 
ное на проверку наиболее критических рисков качества системы, зало- 
жим фундамент анализа рисков качества. 

По аналогии рассмотрим коллег-программистов. Многие методологии 
разработки предписывают, чтобы сбор требований проводился перед про- 
ектированием и реализацией системы. Сбор требований позволяет бизнес- 
аналитикам, проектировщикам системы и программистам создавать систе- 
мы, удовлетворяющие ожиданиям пользователей и заказчиков. Пропуск 
фазы сбора требований может привести к построению системы, которая ос- 
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нована на замечательных идеях и титанических усилиях рабочей группы 
проекта, но которая не будетудовлетворять требованиям заказчиков и поль- 
зователей. Точно так же анализ рисков качества позволяет понять, что озна- 
чает наличие достаточного качества у системы, предназначенной для тести- 
рования, и каким образом можно распознать, что это не так. 


Процесс анализа рисков качества 


Процесс анализа рисков качества может быть прямым, как показано в 
описании Процесса 3. Возможно, что в ходе проекта потребуется повто- 
рить процедуру анализа рисков. Подходящее время для этого — основные 
рубежи (тИезопез), в частности окончательное завершение разработки 
требований, архитектуры или кода. 


Группа тестирования Джамала проводит анализ 
рисков качества 


После разговора с менеджером продукта Кейт Эрнандес и менеджером 
разработки Дженни Кауфман тест-менеджер Джамал Браун, отвечающий 
за комплексное и системное тестирование, некоторое время провел за сбо- 
ром информации о Суматре и подсистеме управления документооборо- 
том. Подсистема управления документооборотом должна предоставить 
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контактирующ 
кессе тестир 


пользователям возможность создавать, обновлять, организовывать поиск 
и совместно использовать большие множества документов. Основным це- 
левым рыночным сегментом пользователей этой функциональности явля- 
ются юридические компании. Частью их работы является создание, сохра- 
нение, снабжение ссылками больших объемов крупных документов, 
относящихся к делопроизводству. Подсистема документооборота должна 
взаимодействовать с системами управления иерархических хранилищ в 
режимах онлайн (на диске), почти онлайн (на оптическом дисководе с ав- 
томатической сменой дисков) и оффлайн (на ленте). 


Процесс 3. Процесс анализа рисков качества 


№ этапа Этап Выполнено? 


1. Определить ключевых лиц, заинтересованных в тестирова- п 
нии и качестве. Добиться их согласия на участие в работе по 
анализу рисков качества. 


2. Сделать для ключевых заинтересованных лиц обзор существую- а 
щих методик и методов анализа рисков качества. Если уместно, 
предложить методику для практического применения в проек- 
те. Достичь консенсуса в выборе предлагаемых методов. 


3. Собрать идеи ключевых заинтересованных лиц о рисках каче- г 
ства, о видах ошибок, связанных с этими рисками, о влиянии 
на качество этих проблем и о расстановке рисков по приори- 
тетам. Определить рекомендуемые действия по снижению ка- 
ждого риска. 


4. Сообщать о любых ошибках, обнаруженных в других проект- п 
ных документах в ходе анализа, в том числе о неудачных 
и пропущенных требованиях, проблемах, связанных с архи- 
тектурой ит.д. 


5. Документировать риски качества в соответствии с выбранной п 
методикой. Разослать документ ведущим заинтересованным 
лицам. При необходимости повторить шаги 3 — 5 для заверше- 
ния анализа рисков качества, расстановки приоритетов и вы- 
работки рекомендуемых действий. 


6. Поместить документацию с анализом рисков качества в про- О 


ектную библиотеку или систему управления конфигурацией. 
Организовать контроль над изменениями документации. 


38 


Часть 1. Планирование 


Затем Джамал переговорил с Джоном Албертсоном, вице-президен- 
том департамента по поддержке разработок, которому непосредственно 
подчиняется группа тестирования Джамала. Джамал рассказал Джону, 
что познакомился с методикой анализа риска качества под названием 
“Анализ видов ошибок и их влияния” (ЕаЙиге Моде апа Ейесі Апаїубіз, 
ЕМЕА). Он также пообщался с сотрудниками, которые уже работали по 
этой методике. Сучетом всего комплекса проблем, с которыми столкнул- 
ся Джамал в ходе работы над последними двумя версиями при поиске кон- 
сенсуса при определении областей системы, покрываемых тестировани- 
ем, он предположил, что инструментарий ЕМЕА мог быть помочь в 
разрешении такого рода проблем. Джон поддержал предложение Джама- 
ла апробировать эту методику. 

Далее Джамал отправил по электронной почте сообщение Кейт, 
Дженни, Бобби Макдениэльсону, менеджеру по вопросам удобства ис- 
пользования, Максу дель Оро, вице-президенту по маркетингу, и Косимо 
Неграеву, менеджеру по поддержке пользователей. Джамал сообщил им, 
что начинаетанализ рисков качества для определения областей системы, 
нуждающихся в тестировании, и что он хотел бы использовать методику 
анализа видов ошибок и их влияния. Он предложил провести день за пре- 
делами офиса, чтобы определить риски качества и расставить их по при- 
оритетам сразу же, как будет завершен первый черновой вариант специ- 
фикаций требований. В течение нескольких дней Джамал получил 
согласие всех участников, в результате ассистент Кейт по административ- 
ным вопросам зарезервировала помещение под семинар в местном отеле 
за неделю до его проведения. 


№ этапа Этап Выполнено? 
1. Определить ключевых лиц, заинтересованных в тестирова- 


нии и качестве. Добиться их согласия на участие в работе по 


анализу рисков качества. 


2. Сделать для ключевых заинтересованных лиц обзор сущест- 
вующих методик и методов анализа рисков качества. Если уме- 
стно, предложить методику для практического применения в 


проекте. Достичь консенсуса в выборе предлагаемых методов. 


К началу семинара по анализу видов ошибок и их влияния Кейт и Макс 
выпустили первую черновую версию спецификаций требований и было 
проведено ее обсуждение. Все участники предстоящего семинара присут- 
ствовали на совещании, где обсуждались требования, поэтому не было не- 
обходимости резервировать время на семинаре для обсуждения требова- 
ний к продукту. 

Насеминаре Джамал познакомил присутствующих с методикой ЕМЕА 
и с идеей мозгового штурма . Он отметил, что в данном случае примене- 
ние методики должно быть ограничено проблемами, которые могут воз- 
никнуть в Суматре, и призвал не рассматривать проблемы, которые, ве- 
роятно, еще остаются в текущей (3.0) версии продукта ЅреедуМтгіќег. 
Чтобы начать работу, Джамал обозначил несколько общих категорий 


Более подробно о ЕМЕА см. 5батацз, “Райите Моде апа Еўе Апабузіз". Краткое изложение 
методики приводится в справочнике МсОегтоц ег а1., " ТАє Баѕісѕ оў ЕМЕА". 
} 
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рисков качества, под которые могли подпадать отдельные виды ошибок. 
В таблице 2.1 приводится перечень, представленный Джамалом участни- 
ка семинара. 


Таблица 21. Общие категории рисков качества для продукта ЗреедуМ/ ег 


Категория риска качества Проблемы, соответствующие категории 


Функциональность Проблемы, в результате которых не работают конкретные 


Нагрузка, производитель Проблемы обработки ожидаемых пиковых нагрузок при 


ность, объем параллельной работе пользователей 

Надежность, стабильность Проблемы, при которых система слишком часто зависает 
работы или долго не восстанавливается 

Перегрузки, обработка оши- Проблемы, возникающие ввиду превышения допустимых 
бок и восстановление пиковых нагрузок или из-за обработки недопустимых усло- 


вий (например, побочный эффект от сознательно внесен- 
ных ошибок) 


Обработка дат и времени Ошибки в математических действиях с датами и временем, 
в их форматировании, в планируемых событиях и других 


операциях, зависящих от времени | 
Качество данных Ошибки в обработке, хранении или извлечении данных | 


Производительность Проблемы с временем завершения задач при ожидаемой 
| загрузке 
Локализация Проблемы, связанные с локализацией продукта, в том чис- 


ле в обработке страницы символов, языковой поддержке, 
в использовании грамматики, словаря и тезауруса, а также 


в сообщениях об ошибках и файлах помощи 


Безопасность Проблемы в защите системы и охраняемых данных от мо- 
шеннического и злонамеренного использования 
Установка /: перенос Ошибки, которые препятствуют поставке системы 
Документирование Ошибки в руководствах по установке и работе с системой 
для пользователей и системных администраторов 
Интерфейсы Ошибки в интерфейсах м. компонентами 


Используя этот перечень в качестве затравки, Джамал вместе с участ- 
никами семинара приступил к мозговому штурму, выделяя те отдельные 
проблемы, которые подпадают под каждую из категорий рисков, и прове- 
ряя, нет ли пропущенных категорий. Макс обнаружил, что пропущена ка- 
тегория “удобство использования”, а Косимо добавил конкурентные не- 
достатки. После того как были предприняты усилия по устранению 
избыточной информации и комбинированию пересекающихся проблем, 
группа выделила около 80 отдельных проблем. 

Имея перечень видов ошибок, теперь можно расставить риски, свя- 
занные с ними, по приоритетам и определить действия по смягчению 
критических рисков. Джамал пояснил, что для оценки рисков он исполь- 
зует упрощенную методику анализа видов ошибок и их влияния. Он по- 
просил участников семинара для каждого вида ошибок рассмотреть три 
фактора: серьезность, приоритетность и вероятность — и проранжиро- 
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вать их по шкале от 1 (наибольший риск) до 5 (наименьший риск).Серьез- 
ность — значимость влияния ошибки для данного вида ошибок, принима- 
ет одно из возможных значений от 1 (наиболее разрушительная) до 5 
(наименее разрушительная). 


1. 


2. 


Потеря данных. Ошибки, относящиеся к этому виду ошибок, могут 
вызвать потерю пользовательских (конечного пользователя, опе- 
ратора системы и т.п.) или системных данных. 


Потеря функциональности. Ошибки, относящиеся к этому виду оши- 
бок, могут заблокировать использование основной функциональ- 
ности (могут включать в себя и нефункциональные проблемы, на- 
пример связанные с производительностью, которые вызывают 
неприемлемые задержки в использовании функций). 


Потеря функциональности с наличием обходного пути. Ошибки, относя- 
щиеся к этому виду, могут заблокировать использование основной 
функциональности, но для пользователя существует разумный об- 
ходной путь. 


Частичная потеря функциональности. Ошибки, относящиеся к этому 
виду, могут заблокировать использование некоторой несуществен- 
ной части функциональности. 


Косметическая ошибка. Ошибки, относящиеся к этому виду, допуска- 
ют нормальное функционирование системы, но со значительными 
недостатками (в особенности, в пользовательском интерфейсе или 
в способности системы реагировать на запросы пользователя). 


Приоритетность — значимость исправления ошибки для этого вида 
ошибок либо из-за влияния на способность системы соответствовать тре- 
бованиям пользователей, либо из-за проблем в логике проекта, несоот- 
ветствия стандартам или инструкциям, либо в связи с другими соображе- 
ниями, связанными с бизнесом, от 1 (наиболее важно исправить) до 5 
(наименее важно исправить). 


1. 
2. 


3. 
4. 


5. 


Неотложно. Ошибки, относящиеся к этому виду, могут потребовать 
немедленного исправления. 


7 : У 
Существенно. Ошибки, относящиеся к этому виду, скорее всего, бу- 


дут обязательно исправлены к моменту выпуска версии. 


Значимо. Ошибки, относящиеся к этому виду, могут существенно 
снизить ценность системы для одного и более заказчиков или поль- 
зователей. 


Желательно. Ошибки, относящиеся к этому виду, могут быть исправ- 
лены к выпуску текущей версии, если это будет возможно в рамках 
ограничений по функциональности, бюджету и срокам, в против- 
ном случае они будут исправлены в следующей версии. 


На усмотрение. Ошибки, относящиеся к этому виду, будут исправле- 
ны в одной из будущих версий, если это позволит приоритетность. 


Вероятность — возможность возникновения ошибки этого вида и 
всех ее проявлений, от 1 (наиболее вероятно) до 5 (наименее вероятно). 
На величину этого рейтинга влияют три фактора. Во-первых, для всех 
ошибок, включенных в этот вид, устанавливается, велика ли вероятность 
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того, что они могут появиться в системе, с точки зрения факторов техни- 
ческого риска: сложности и предыдущей истории дефекта. Во-вторых, ве- 
лика ли вероятность того, что ошибки будут пропущены разработчиками 
(не включая тестировщиков)? И, в-третьих, велика ли вероятность того, 
что они будут проявляться в повседневном использовании, в текущих дей- 
ствиях пользователя или при инсталляции? Если программисты не вне- 
сут ошибок, вызывающих проблему, или в ходе рецензирования кода та- 
кие ошибки будут обнаружены, или пользователи не будут применять 
систему таким образом, что столкнутся с этими ошибками, тогда риск ми- 
нимален. Если указанные ошибки существуют, при рецензировании кода 
они были пропущены, а пользователи столкнутся с ними, то риск велик. 


1. Очень вероятно. Почти наверняка окажет влияние на работу всех 
пользователей, функций или инсталляционных программ. 


2. Вероятно. Может оказать влияние на работу многих пользователей, 
функций или инсталляционных программ. 


3. Возможно. Может повлиять на работу некоторых пользователей, 
функций или инсталляционных программ. 


4. Маловероятно. Может оказать влияние на работу ограниченного 
числа пользователей, функций и инсталляционных программ. 


5. Очень маловероятно. Практически не повлияет на работу большинст- 
ва пользователей, функций или инсталляционных программ. 


Произведение трех значений — серьезности, приоритетности и веро- 
ятности — дает приоритет риска (гізК ргіогігу питрег, ВРМ), который мо- 
жет принимать значение от 1 (крайне опасно) до 125 (практически несу- 
щественно). 

После установления приоритетов рисков участники семинара опреде- 
лили рекомендуемые действия по снижению рисков в ходе тестирования. 
В основном действия распределились по четыремуровням тестирования . 


1. Подробное тестирование (ехіепѕіхе). Тестировщики должны сделать 
попытку в рамках проектных ограничений покрыть функции и свой- 
ства, относящиеся к этим рискам качества, как вширь, так и вглубь. 
При рассмотрении ошибок, относящихся к этим рискам, готовя от- 
чет об ошибке, тестировщики должны потратить определенное вре- 
мя на воспроизведение и локализацию проблемы. 


2. Сбалансифованное тестирование (Баїапсед). Тестировщики должны 
принимать во внимание ограничения бюджета и сроков при созда- 
нии широкого, не обязательно глубокого, покрытия тестами функ- 
ций и свойств, попадающих под эти риски качества. Обнаружив 
ошибки, связанные с этими рисками, тестировщики должны огра- 
ничивать время на воспроизведение и локализацию проблем, осно- 
вываясь на оценке сераедности и приоритетности ошибки. 


1 Стив Сплайн (5:еуе 5ріаіп), один из рецензентов этой книги, указал на то, что можно так- 
же рассмотреть относительные затраты на тестирование в сравнении с другими мерами, ко: 
торые можно было бы использовать для снижения данного вида риска. Мы также могли бы 
перепроектировать систему, застраховать ее, использовать рецензирование кода и другие 
подходы. 
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3. Тестирование по возможности (оррогіапігу). Если в ходе проектиро- 
вания, разработки или выполнения очередного теста тестировщи- 
ки могут соразмерять деятельность по настройке, выполнению тес- 
тов, операциям по демонтажу системы или подготовке данных для 
проведения тестов, чтобы выполнить поверхностное тестирова- 
ние некоторых или всех условий, относящихся к данному риску, то 
в этом случае они должны выполнить такой тест. Тестировщики 
должны ограничивать время на воспроизведение и локализацию 
ошибки на основе оценки ее серьезности и приоритетности. 


4. Информирование о наблюдаемых дефектах. Тестировщики не должны 
проектировать или разрабатывать тесты для этих категорий рис- 
ков качества, но обязаны информировать об ошибках, относящих- 
ся к этим рискам, при их обнаружении. Тестировщики должны ог- 
раничивать время на воспроизведение и локализацию ошибки на 
основе оценки ее серьезности и приоритетности. 


Рабочая группа проекта “Суматра” присвоила категории тестирова- 
ния на основе значений приоритета рисков. Рискам со значениями от 1 
до 8 присвоена категория “подробное тестирование”. Рискам со значе- 
ниями от 9 до 24 присвоена категория “сбалансированное тестирование”. 
Рискам со значениями от 25 до 48 присвоена категория “тестирование по 
возможности”. Рекомендовано не прбводить тестирования для рисков с 
приоритетом выше 50, но информировать о таких ошибках. Исключения 
сделаны для некоторых рисков, относящихся к граничным условиям. На- 
пример, два вида рисков для качества данных получили приоритет, рав- 
ный 8, но рабочая группа рекомендовала сбалансированное тестирова- 
ние, поскольку, по ее мнению, подробное тестирование потребует 
слишком много времени для такого уровня риска. 


№ этапа Этап Выполнено? 
3. Собрать идеи ключевых заинтересованных лиц о рисках каче- 


ства, о видах ошибок, связанных с этими рисками, о влиянии 
на качество этих проблем и о расстановке рисков по приори- 
тетам. Определить рекомендуемые действия по снижению ка- 
ждого риска. й 


В ходе анализа видов ошибок и их влияния рабочая группа проекта 
"Суматра" обнаружила две области, пропущеннье в спецификациях тре- 
бований. Во-первых, в требованиях не описано, каким образом система 
должна обрабатывать права доступа; вместо этого она полагается по умол- 
чанию на контроль при входе в сеть. Участники семинара выразили об- 
щее мнение, что система должна также позволять пользователям изме- 
нять их учетные записи внутри самой системы документооборота. Во- 


В некоторых случаях я добавляю поверхностное тестирование как категорию между сбалан- 
сированным тестированием и тестированием. по возможности. Поверхностное тестирование 
предполагает отбор небольшого числа рисков качества в определенной области системы. 
Можно было бы также добавить категорию “не тестировать» после категории “информирова- 
ние о наблюдаемых дефектах». “Не тестировать» означает, что об ошибке, относящейся к дан- 
ным рискам качества, не будет сообщено даже в случае ее обнаружения. 
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вторых, в спецификациях требований ничего не говорится о том, что 
должно происходить, если библиотекарь не загрузит объект — ленту, 
компакт-диск или оптический диск — в устройство. Эти находки служат в 
качестве примера раннего обнаружения дефектов в документе, описы- 


вающем требования. 
№ этапа Этап Выполнено? 
4. Сообщать о любых ошибках, обнаруженных в других проект- и 


ных документах в ходе анализа, в том числе о неудачных и 
пропущенных требованиях, проблемах, связанных с архитек- 
турой ит.д. 


По итогам семинара Джамал подготовил документ с анализом видов 
ошибок и их влияния (см. рис. 2.1). Он разослал документ всем участникам 
семинара, а также Гарольду Джоунзу, вице-президенту по системному про- 
граммированию. Адресаты высказали несколько замечаний, повышающих 
или понижающих значения серьезности, приоритетности и вероятности, 
но в целом они сочли документ приемлемым. Джамал внес заключитель- 
ные изменения и добавил документ в проектный репозиторий. 


№ этана Этап Выполнено? 
5. Документировать риски качества в соответствии с выбранной і 


методикой. Разослать документ ведущим заинтересованным 
лицам. При необходимости повторить шаги $ — 5 для заверше- 
ния анализа рисков качества, расстановки приоритетов и вы- 
работки рекомендуемых действий. 


6. Поместить документацию с анализом рисков качества в про- 


ектную библиотеку или систему управления конфигурацией. 
Организовать контроль над изменениями документов. 


Завершив анализ рисков качества, Джамал достиг консенсуса с груп- 
пой управления проектом “Суматра” относительно того, какие области 
должны быть протестированы. Могут ли теперь Джамал и его бравая ко- 
манда тестировщиков нацелиться на проверку всех выделенных облас- 
тей? Чтобы ответить на этот вопрос, Джамал приступил к оценке затрат 
и разработке плана. Этому посвящены несколько следующих глав. 


Построение успешного процесса анализа рисков 
качества 


Проведение мероприятий по анализу рисков качества, аналогичных тому, 
в котором участвовали Джамал и его коллеги, требует больших затрат вре- 
мени и сил, однако это очень полезная работа. (Менее формальный анализ 
рисков может быть дешевле и проще, чем анализ видов ошибок и их влия- 
ния.) Правильно. организованный процесс анализа рисков качества вклю- 
чает в себя следующие действия и дает следующие преимущества. 
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Привлечение подходящих участников 


Любой сотрудник компании может иметь мнение по поводу рисков каче- 
ства системы и ожиданий качества со стороны заказчиков и пользовате- 
лей. При проведении анализа рисков качества подбор участников осно- 
вывается не на их мнениях, а на том, кто обладает интуицией и может 
понять, что определяет качество и какие риски качества системы сущест- 
вуют. Должны рассматриваться: 


в Цели, скоторыми заказчики приобретают систему, а пользователи 
ее применяют ` | 


Полезные свойства системы 


Частная задача, которую решает система, и общие цели компании, 
предполагающей использовать систему 


є Стратегический маркетинг и направление технического развития 
продуктового ряда (иногда называемые направлением развития про- 
дукта) или семейства систем, а также компаний, разрабатываю- 
щих, сопровождающих, приобретающих и использующих систему 


' м Процесс и технологии, применяемые в проектировании, разработ- 
ке и сопровождении системы 


= Возможности и ограничения процесса тестирования, группы тес- 
тирования и системы тестов 


В таблице 2.2 представлены роли потенциальных участников процес- 
са анализа. Заметим, что компании, разрабатывающие рыночные или за- 
казные продукты, обычно отличаются от компаний, которые производят 
продукты для внутреннего употребления, поэтому в вашей компании не- 
обязательно будут существовать все роли. 

Таблица 2.2 — это только фрагмент списка участников, которые могут 
быть привлечены к анализу рисков. Нужно ли (да и хочется ли) приглашать 
всех? Вероятно, нет. Анализ рисков качества таков, что для требований ну- 
жен один список участников, для архитектуры — другой, для разработки — 
третий. Участники со стороны группы тестирования могут оставаться 
теми же, либо тест-менеджер делегирует тестировщиков, которые являют- 
ся экспертами в областях деятельности низкого уровня, а сам участвует 
персонально только в анализе требований. 

Некоторые из заинтересованных лиц могут быть недоступны для уча- 
стия в анализе рисков качества. Наиболее важные лица — это заказчики и 
пользователи. В идеале, если возможно, их необходимо привлекать кана- 
лизу рисков качества на основе требований, и компании, разрабатываю- 
щие системы для внутреннего применения, могут иногда так делать. Од- 
нако в проектах по созданию рыночных и заказных систем заказчики и 
пользователи обычно не принимают участия в процессе анализа рисков 
качества, причем будущие заказчики и пользователи часто неизвестны за- 
ранее. В этом случае те ключевые заинтересованные лица, которые наи- 
более плотно работают с потенциальными заказчиками и пользователя- 
ми — менеджеры продаж, маркетинга, техподдержки и т.п., - в ходе 
анализа должны представлять интересы пользователей и заказчиков, вы- 
ступая в качестве доверенных лиц отсутствующих участников. 
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Таблица 2.2. Вероятные участники процесса анализа рисков качества 


Роль в процессе анализа 


Роль в проекте (компании) 


Позиционирование системы Менеджер по маркетингу : 


нарынке 


Сбор системных требований Бизнес- 


, систем- 
ные аналитики 


Оценивает 


Ценность системы для заказ- 
чика или пользователя 


Требования пользователей 
и основное предназначение 
системы 


Выработка стратегического Менеджер по маркетинту, План развития продукта или 


направления для продукто- 
вого ряда 


Выбор стратегического на- 
правления технологического 
развития и руководство им 


менеджер продукта, главный 
архитектор, главный науч- 
ный сотрудник 


Главный архитектор, менед- 
жер разработки, вице- 
президент по разработке, 


главный научный сотрудник, 
главный информатор 


системы 


Техническая сторона долго- 
срочного развития 


Проектирование системы, 
предназначенной для тести- 
рования 


Сборка системы, предназна- 
ченной для тестирования 


Проектирование системы 
тестов 


Документирование свойств 
системы 
Тестирование системы 


Взаимодействие с заказчика- 
ми и пользователями 


Работа с производителями 
подсистем 


Поставка системы 


Бизнес-аналитик, системный 
аналитик, архитектор про- 
дукта, менеджер разработки, 
ведущий программист 


Менеджер разработки, веду- 
щий программист, програм- 
мист, технический персо- 
нал, системный аналитик 


Тест-менеджер, ведущий тес- 
тировщик’ 


Технический писатель, ме- 
неджер технических публи- 


м 


кации 


Ведущий тестировщик, 
тестировщик, тестировщик- 
лаборант 


Менеджер по продажам, тор- 
говый агент, специалист по 
продажам, сотрудник по свя- 
зи с клиентами, бизнес- 
аналитик 


Инженер по качеству со сто- 


роны поставщика 


Инженер сборок, менеджер 
сборок, администратор ин- 
формационной системы, 
ИТ-менеджер 


Ограничения системной 
архитектуры 


Ограничения реализации 
системы 


Ограничения тестирования 


Что вы сообщаете пользова- 
телям о реальном поведении 
системы 


Дефекты, обнаруженные 

в системах, разработанных 
ранее, сложные тестовые 
сценарии 


О каких свойствах системы 
беспокоятся заказчики 


Что в подсистемах тестирова- 
ли их производители, извест- 
ные дефекты в подсистемах 


Технические проблемы, 
связанные с разработкой 
системы 
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Таблица 2.2 (продолжение) 


Рольв процессе анализа 


Поддержка среды поставки 


Поддержка пользователей 
и заказчиков 


Устранение дефектов из раз- 
вернутой системы 


Роль в проекте (компании) Оценивает 


Администратор сети, сис- Работа сетей, аппаратного 

темный администратор, ме- обеспечения, сосуществова- 

неджер конфигурации, адми- ние различных компонентов 

нистратор информационной ПО; плановые процедуры; 

системы процедуры обработки ис- 
ключительных ситуаций 
(например, восстановление 
после сбоя) 


Параметры реальных пользо- 
вателей, известные дефекты 


Менеджер поддержки поль- 
зователей, менеджер техни- 
ческой поддержки, мейед- 
жер поддержки заказчиков, 
менеджер по работе с заказ- 
чиком, сотрудник системы 
поддержки пользователей 
в сети, администратор ин- 
формационной системы 


Сотрудник службы поддержки Известные дефекты, пробле- 
заказчика, программист служ- мы внесения изменений 

бы технической поддержки,  вразвернутую систему 
технический персонал 


Финансирование или по- 


мощь в финансировании раз- внешний) 


работки или сопровождения 
системы 


Явное или косвенное 
использование системы 


Ответственность за процес- 
сы оценки качества 


Персональная ответствен- 
ность за качество продукта 


Заказчик (внутренний или Проблемы, решение кото- 
рых ожидается с помощью 
системы, или новые полез- 
ные возможности, которые 


привнесет система 


Как пользователи применяют 
систему для решения задач 
или получения прибыли; како- 
вы типичные наборы данных 
и сценарии использования 
системы; какие проблемы 
были у пользователей ранее 


Различные классы пользова- 
телей 


Специалист по качеству, ме- 


неджер группы процессов 
разработки ПО, менеджер 


по качеству 


Директор по качеству, гене- 


Гарантия согласованности 
процесса и качества в ходе 
разработки всей системы 


Насколько должен быть ка- 


чественным продукт, чтобы 
его можно было выпустить 
под маркой компании 


ральный директор, руково- 
дитель администрации, пре- 
зидент 


Мой опыт анализа рисков качества показывает, что наилучшие резуль- 
таты достигаются, когда привлекается максимально возможное число за- 
интересованных лиц с разными интересами и наличием квалификации 
в разных областях. Чем больше обнаруживается точек зрения в компа- 
нии, тем сложнее перечень рисков и более точной будет расстановка при- 
оритетов рисков. Хотя для анализа рисков качества действительно полез- 
ны спецификации требований и архитектуры, привлечение участников, 
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которые являются специалистами в разных областях, — более важный 
фактор успеха процесса анализа рисков. Позвольте проиллюстрировать 
данный факт двумя историями. 

В первом случае ведущие тестировщики и я как тест-менеджер применя- 
ли анализ видов ошибок и их влияния, после того как проектная группа под- 
готовила качественную проектную документацию, в том числе специфика- 
ции требований и архитектуры. Однако проектная группа не участвовала в 
проведении анализа. Вместо этого мы отправляли по электронной почте 
черновики документов сотрудникам рабочей группы проекта. Многие из 
ключевых заинтересованных лиц отказались потратить время, чтобы пре- 
доставить нам полезную информацию. Кончилось все тем, что мы останови- 
ли выполнение тестов, на которые мы потратили много времени и сил, раз- 
рабатывая данные, сценарии, тестовую среду и т.п., посередине процесса, 
поскольку наши оценки степеней рисков не совпали с приоритетами проек- 
та. Другими словами, преимуществ от определения того, что тестировать, 
ачто— нет, небыло получено, поскольку заинтересованные лица не участво- 
вали воценке. Проектная документация оказалась не в состоянии адекватно 
заменить вклад разных специалистов в анализ рисков качества. 

Во втором случае метод анализа видов ошибок и их влияния использо- 
вался при отсутствии какой бы то ни было проектной документации. Груп- 
па специалистов различных направлений, участвовавшая в процессе ана- 
лиза рисков качества, хранила все знания, необходимые для проведения 
совещаний, у себя в головах. Анализ оказался успешным. Предотвращение 
дефектов за счет изменений в процессе программирования и обнаружение 
ошибок за счет правильного выбора приоритетов тестирования дали воз- 
можность своевременно выпустить версию качественного продукта. 

Конечно, отсутствие документации требований и архитектуры отри- 
цательно повлияло на ход проекта, включая тестирование. Однако суще- 
ственного влияния на анализ рисков качества это не оказало. 


Выбор подходящей методики 


Существует много методик, которые могут использовать тестировщики 
при анализе рисков качества. Я хорошо знаком с четырьмя методиками, 
которые регулярно и успешно применяются. 


и Неформальный анализ. Определить потенциальные проблемы систе- 
мы, а затем совместно с ключевыми заинтересованными лицами 
расставить их по приоритетам. В качестве источников списка по- 
тенциальных проблем могут использоваться книги, стандартные 
списки проблем качества ПО, списки проблем предметной облас- 
ти, общие знания о видах дефектов, присущих типу системы, кото- 
рая находится в разработке . 


в. Метод стандарта АМ51/150 9126. Для шести характеристик качества - 
функциональности, надежности, удобства использования, произво- 


Четыре перечня типичных дефектов системы можно найти в главе о систематизации де- 
фектов в книге Бориса Бейзера (Вогіз Вешег) "бо/їшате Тезійпо Тесітідиея", в приложении, со- 
держащем перечень типичных ошибок, в книгах Сема Канера и др. (Сеш Капег её а!) " Теяїта 
Сотриїет бо/їшаті", Петера Ноймана (Реег Меитапл) “Сотшригег-Кејагеа В15Кз» и в списке рис- 
ков качества программных и аппаратных средств в книге Рэкса Блэка 5 Віаск) "Мапаріпе 
йе Тезйта Рғосеѕѕ, Бесопа Е@ от”. 
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дительности, удобства сопровождения и мобильности (для краткого 
обозначения шести характеристик качества в оригинале используєт- 
ся сокращение ЕКОЕМР по первым буквам английских слов, обозна- 
чающих эти характеристики) — определяются признаки качества, 
метрики для измерения качества системы на основе каждого призна- 
ка качества и способ перевода этих метрик в оценки качества . 


и Методика стоимости обнаружения проблемы (соѕі ої ехроѕиге, СОЕ). 
Определяются потенциальные проблемы и их влияние, а затем 
оцениваются стоимость наличия проблем для бизнеса и вероят- 
ность их возникновения. 


и Анализ видов ошибок и их влияния (ЕМЕА). Определяются потенци- 
альные проблемы, оценивается их влияние (на заказчиков и поль- 
зователей), а затем выполняется классификация (с учетом мнений 
заинтересованных лиц) по серьезности (влияние на систему), при- 
оритетности (влияние на бизнес) и вероятности (возможность воз- 
никновения дефекта). 


Методики перечислены в порядке усложнения структуры и увеличе- 
ния точности. В тех случаях, когда это уместно, я предпочитаю точность 
и количественные оценки и, следовательно, использую метод анализа ви- 
дов ошибок и их влияния. Однако я обнаружил, что этот метод не всегда 
работает в неформальном или быстро меняющемся контексте проекта. 
И явыбираю ту методику, которая соответствует общему уровню структу- 
ры истепени точности, присущим проекту, находящемуся в работе. Мето- 
ды формального анализа — анализ видов ошибок и их влияния — и метод 
стоимости обнаружения проблемы требуют привлечения проектной 
группы к участию в продолжительном совещании. Неформальный под- 
ход обычно означает встречи один на один с ключевыми заинтересован- 
ными сторонами и последующее рецензирование короткого документа 
для достижения согласия. Таким образом, неформальный подход приво- 
дит купрощенному процессу, который, вероятно, проще реализовать. 

Более структурированные и формализованные подходы позволяют до- 
биться более тщательно откалиброванного процесса тестирования с более 
точно определенными целями. В примере с продуктом “Суматра” присвое- 
ние уровней тестирования, основанное на значениях приоритета рисков, — 
пример точного определения целей. Однако применение таких методов 
требует большей квалификации и знаний, чем применение неформальных 
методов. Например, мне потребовалось поучаствовать в шести или семи 


1 см. руководство по стандарту АМ51/15О 9126. Обсуждение применения стандарта при- 
водится в книге Вана Веенендааля и др. (уап Уеепепдза! ег.а|.) “Меаѕигіпр бойжаге Ргодисе 
Омаїпу Читая Тезбпя”. Этот вопрос также рассматривается в книге Поула (Ро!) и др., посвя- 
щенной Т-МАР. Кроме того, Стефан Кан (Ѕїерһеп Кап) в “Мет; апа Моде іп 5о/їшате диайбу 
Епріпегтіпр, бесопа Еййіют” дает ссылки на два других списка характеристик качества с запоми- 
нающимися сокращениями на английском языке: функциональность, удобство использова- 
ния, надежность, производительность и удобство сопровождения (ЕГОКР5), а также устой- 
чивость, удобство использования, производительность, надежность, удобство установки, 
удобство сопровождения и работоспособность (СОРЕМО). Эти два сокращения можно до- 
бавить к ранее рассмотренному способу ЕКОЕМР. Наконец, в главе 11 книги “бойшате 
Еефийтетет!5” Карл Вигерс (Кай УЛерегз) приводит интересное суждение по поводу атрибу- 
тов качества программ, включая компромиссы между атрибутами. 
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проектах, чтобы почувствовать себя опытным и уверенно использовать ана- 
лиз видов ошибок и их влияния. Если нет времени на обучение, не надо пы- 
таться сразу объять необъятное. Чтобы просто погрузиться в анализ рисков 
качества, возможно, лучше начать с неформального подхода. 

Можно перейти от неформальных методов к формальным, если вы- 
явится необходимость в более точной оценке. Я часто использую нефор- 
мальную методику в качестве базы для методики ЕМЕА как раз для получе- 
ния исходного множества категорий рисков качества. 

Какую методику ни использовать, все равно желаемым результатом яв- 
ляется список рисков качества системы, расставленных по приоритетам. 
Значения приоритетов, присвоенные рискам, определяют в основном 
необходимый объем тестирования. Обычно серьезные риски требуют 
тщательного тестирования, риски средней степени нуждаются в ограни- 
ченном тестировании, несущественные риски не требуют тестирования 
вовсе. 

Уровням риска могут быть присвоены нечисловые (например, высо- 
кий, средний, низкий, отсутствует) или числовые значения. Мне дове- 
лось работать с разными числовыми шкалами. Предпочитаю шкалу от 1 
до 5 впорядке убывания для каждой изтрех переменных в методе анализа 
видов ошибок и их влияния. Однако один из участников моего семинара 
рассказал, что его сотрудник использует шкалу от 0 до 9 в порядке возрас- 
тания в методике определения качества функциональности (ОцаШу 
Кипсціопа! реріоутепі, ОКР), причем 9 означает высокий, 3 — средний, 
1- низкий, 0 — нет. Стаматис (0. Н. 5гатаці) в книге “Райите Моде апа Е рее 
Апаіузѕіѕ" использует шкалу от 1 до 10 в порядке возрастания. 

Методики стоимости обнаружения проблемы и анализа видов ошибок 
и их влияния различаются способом представления информации, но мной 
было обнаружено, что можно преобразовать результаты, полученные по 
одной методике, в результаты другой. На рис. 2.2 показано, как трансфор- 
мируются результаты анализа видов ошибок и их влияния (см. рис. 2.1) при 
преобразовании в результаты методики стоимости обнаружения пробле- 
мы. Преобразование потребовало около часа времени, включая конверта- 
цию шкалы от 1 до 5 в шкалу для определения качества функциональности. 

Заключительное замечание касается того, что нужно помнить, что нет 
необходимости все время использовать одну и ту же методику, тем более 
на разных фазах проекта. В некоторых случаях может быть полезным 
проведение анализа рисков проблемной области для комплексного и ин- 
теграционного тестирования и анализа рисков проектирования и реали- 
зации для модульного и компонентного тестирования. Вероятно, нефор- 
мального подхода вполне достаточно для модульного и компонентного 
тестирования, в то время как для комплексного и системного тестирова- 
ния потребуется более формализованный подход (методики стоимости 
обнаружения проблемы или анализа видов ошибок и их влияния). По- 
жертвовав совсем немного полнотой состава и координацией специали- 
стов в разных областях и разных проектах, за счет гибкости более просто- 
го процесса, требующего меньших ресурсов, можно продвинуться 
вперед, когда время является критической величиной. 
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Рис. 2.2. Начало отчета о проведении первичного анализа стоимости обнаружения проблемы 
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Отделение немногих важных аспектов от множества 
тривиальных 


Независимо от того, какая методика применяется, сила анализа рисков 
качества зависит от того, насколько удается отделить серьезные риски, 
с которыми нужно тщательно работать, средние риски, которым необхо- 
димо уделить определенное внимание, и незначительные риски, которы- 
ми по большей части можно пренебречь. Можно сравнить методики ана- 
лиза рисков с решетом, которое отсеивает камни и пропускает песок. 

Мне довелось наблюдать естественное развитие группы, анализирую- 
щей риски, когда грубое решето становилось тонким фильтром. Участни- 
ки процесса анализа рисков не спешат принимать грубые решения и про- 
водят скрупулезное исследование, необходимое для того, чтобы отделить 
потенциальные проблемы от простого раздражения. Если этого не про- 
исходит, каждый риск классифицируется как высокий. Это может быть 
верно для систем с особыми требованиями к безопасности, но для боль- 
шинства систем существует большое число ошибок, которые не помеша- 
ютгруппе разработки выпустить версию, либо эти ошибки не связаны ни 
с одним реалистичным сценарием использования системы. 

При качественном тестировании идет поиск дефектов, которые могут 
оказать влияние на мнение пользователей и заказчиков о системе. Как 
правило, есть проблемы, без устранения которых менеджеры продаж, 
маркетинга или технической поддержки задерживают выпуск версии. 
Хотя обычно приветствуется обнаружение других видов проблем в нача- 
ле тестирования, обычно все заканчивается необработанными отчетами 
об ошибках и невыполненными наборами тестов в конце проекта. 

Вышесказанное позволяет четко очертить рамки совещаний, посвя- 
щенных анализу рисков качества. Неверно, что ключевым вопросом на 
них является выяснение того, хотим ли мы, чтобы версия системы не имела 
ошибок определенного вида. Такой вопрос не имеет отношения к реали- 
ям проекта. В принципе все выступают за улучшение качества. Однако 
ключевым вопросом является выяснение того, от чего мы готовы отка- 
заться, чтобы гарантировать, что в версии системы нет ошибок опреде- 
ленного вида. Другими словами, является ли потенциальная проблема ка- 
чества такой, что за ее обнаружение и исправление группа управления 
проектом готова расплачиваться дополнительными финансами на тести- 
рование, ожидаемой прибылью или готова просто удалить эти свойства 
системы в случае задержки выпуска или поставки версии? Таким образом, 
очерчивание рамок анализа рисков качества позволяет более точно рас- 
ставить риски по приоритетам. 


Поиск возможных дефектов до начала тестирования 


Часто результаты анализа рисков качества начинают проявляться еще до 
написания первого тестового сценария. Рассмотрим процесс анализа. 
рисков качества как форму структурированного перекрестного рецензи- 
рования. Как при любом процессе рецензирования, полученные резуль- 
таты могут распространяться и оказывать влияние на весь ход проекта. 
Обычно это происходит тремя основными способами. 
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Во-первых, в ходе анализа могут быть обнаружены противоречивые, не 
являющиеся тестопригодными или нереализуемые требования, слабости 
архитектуры и даже, если проверке подвергается код, потенциально про- 
блемные структуры данных и фрагменты управляющей логики программ. 
В этом смысле анализ рисков качества сводится к рецензированию этих до- 
кументов через уникальную призму рисков качества системы . 

Во-вторых, помимо поиска проблем, процесс анализа рисков качества 
может быть также направлен на поиск решений. Например, в качестве 
действия по снижению определенных рисков могут быть рекомендованы 
более тщательное рецензирование кода, использование формальных ут- 
верждений в системе, пошаговая трассировка выполнения программы в 
критических областях и другие методы безопасного программирования 
и оценки качества. В нашем примере анализ видов ошибок и их влияния 
можно использовать с целью оценки качества проекта “Суматра”. 

В-третьих, процесс расстановки приоритетов выступает в качестве 
раннего предупреждения программистов о том, что будет тестироваться. 
Как отмечал Борис Бейзер, иногда всего лишь “угрозы тестирования” дос- 
таточно для предотвращения ошибок“. Если группе разработки известно, 
на поиск каких дефектов будет ориентировано тестирование, ее участни- 
ки, вероятно, потратят больше времени на проверку работы соответст- 
вующих компонентов системы. 

Таким образом, анализ рисков качества уменьшает число ошибок, ко- 
торые обнаруживаются в ходе тестирования. Как мы увидим в главе 4, ис- 
правление ошибок, обнаруженных на стадиях сбора требований и разра- 
ботки архитектуры, обходится существенно дешевле, чем исправление 
ошибок, обнаруженных на фазе тестирования. До выбора методов, на- 
правленных на предотвращение дефектов, компания должна расстаться 
с использованием непродуктивных способов работы компании. Приме- 
рами способов, мешающих предотвращению ошибок, являются стимули- 
рование или оценка. работы. тестировщика на основе числа дефектов, 
найденных в ходе тестирования. В этом случае сообразительные тести- 
ровщики быстро понимают, что начинают работать против собственных 
интересов, если помогают предотвращению дефектов. 

Когда оценка рисков качества используется для предупредительных 
действий, например для уточнения требований, усовершенствования ар- 
хитектуры, безопасного программирования и других мер по поддержке 
качества, необходимо, чтобы каждый участник этого процесса понимал 
необходимость дальнейшего смягчения важных рисков качества за счет 
соответствующего объема тестирования. Как тестировщик-професси- 
онал я верю в предотвращение дефектов. Однако я также полон профес- 
сионального пессимизма. Как можно узнать, что ошибка предотвращена, 
пока не проведешь тестирование с целью поиска этой ошибки и не убе- 


1 Видеале проектная группа также применяет и другие методы рецензирования требова- 


ний, архитектуры и кода, а не полагается лишь на анализ рисков качества. Например, спосо- 
бы рецензирования требований рассматриваются в книге Карла Вигерса (Кагі УЛевегз) 
“Зоймаге Вединететиз», а также в статье Роджера Драбика (КоЧрег Дгабіск) "Оп-Ттаєй 
Еедизтетет:5” в “ЗоЙшате Теяїто апа Оцаїйу Епріпеетіпр", 01.1, Іѕѕие 3 (Мау/]апе 1999). 


2 Вкниге Бориса Бейзера (Вогіѕ Веігег) “Зойшате Тезійпе Тесітідиеї" есть целый ряд наблюде- 
ний о том, как тестирование выполняет свою миссию и в каких случаях не выполняет. 
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дишься, что єє действительно нет? Как говорит русская пословица: «До- 
веряй, но проверяй». 


Своевременное начало 


В примере с проектом "Суматра" Джамал и его коллеги приступили 
к анализу рисков качества по завершении рецензирования первой чер- 
новой версии документа с описанием требований. Правильно ли вы- 
брано время начала? Группа проекта “Суматра” не имела специфика- 
ций архитектуры, в частности архитектуры сети и программного 
обеспечения, которые могли бы способствовать рассмотрению разно- 
образия видов ошибок, связанных с архитектурой, например состоя- 
ний гонок в базах данных и одиночных точек сбоев в нерезервируемых 
серверах. В дополнение к информированию групп, занимающихся ана- 
лизом рисков качества, о других вероятных проблемах информация об 
архитектуре дает возможностьучастникам увидеть технические риски. 
Это позволяет более точно оценить вероятность вида ошибки, сущест- 
вующего в системе. Таким образом, нужно ли откладывать начало ана- 
лиза рисков качества до завершения подготовки спецификаций архи- 
тектуры? 

До определенной степени ответ на этот вопрос зависит от того, какие 
методы тестирования планируется применять. С одной стороны, если 
есть намерение уделить большое внимание структурному тестированию, 
понимание особенностей архитектуры и реализации системы может 
быть важно для анализа рисков. Если, с другой стороны, тестирование бу- 
дет основано на поведении системы, не очень важно, каким образом уст- 
роена система изнутри. Хотя знание деталей ее устройства позволяет 
улучшить оценку рисков с точки зрения вероятности, на пользователя 
оказывают влияние множество других факторов, которые будут приняты 
во внимание при анализе рисков качества (в частности, факторы, рас- 
смотренные группой “Суматра” при использовании анализа видов оши- 
бок и их влияния). 

Также можно провести анализ рисков качества требований, а после 
завершения спецификаций архитектуры организовать короткое до- 
полнительное совещание по рискам. Более того, можно встретиться 
и в третий раз, когда станет доступной дополнительная информация 
о деталях и компонентах архитектуры. Я бы не рекомендовал ежене- 
дельное обсуждение рисков качества, однако небольшое совещание по 
уточнению оценок рисков качества по достижении основных рубежей 
проекта — отличная идея. По мере того как факторы, влияющие на 
оценку рисков, перевешивают в сторону технологий, список участни- 
ков может изменяться за счет приглашения системных проектировщи- 
ков и старших программистов и исключения сотрудников отделов про- 
даж и маркетинга. 


А 


Готовность к изменениям 


Источники информации, влияющие на оценку рисков, появляются не 
только в моменты достижения рубежей проекта. Приоритеты бизнеса из- 
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меняются во времени даже в хорошо управляемых и стабильных проек- 
тах. Вероятность проблем определенного вида становится очевиднее по 
мере того, как вы получаете опыт тестирования реальной системы. Мож- 
но рассчитывать на дополнительные знания о рисках качества системы 
в процессе проектирования и разработки системы, а также в процессе 
разработки тестов. Иногда оказывается, что мы недооценили ресурсы и 
потребуется еще время на достижение уровня тестирования, согласован- 
ного в ходе анализа оценки рисков. Это означает, что необходимы уточ- 
нения и подстройки процесса в ходе всего подпроекта тестирования. 
Процесс анализа рисков качества нуждается в непрерывном изучении 
рисков и в улучшении управления этим процессом. 

Традиционный подход к управлению изменениями состоит в помеще- 
нии документа с описанием анализа рисков качества в проектный репози- 
торий и постановке под контроль коллегиального органа, как правило, 
группы управления изменениями (Сһапре Сопио! Воага, ССВ) (см. гла- 
ву 16). По мере того как группа проекта получает новую информацию 
о рисках и по достижении рубежей проекта, она повторяет анализ. Тест- 

‚менеджер или кто-то другой, отвечающий за процесс анализа рисков, бе- 
рет документ с описанием анализа рисков из репозитория на изменение, 
обновляет его, а затем выносит обновленный документ на утверждение 
совещанием группы управления изменениями. В то же время вполне воз- 
можно, что в ходе анализа рисков выясняется, что некоторые риски ста- 
ли менее вероятными, например, если установлено, что сетевая или 
серверная архитектура, ‘используемая для реализации некоторого фраг- 
мента системы, является устойчивой к некоторому сбою. Обычно обнов- 
ленные результаты анализа рисков качества требуют некоторого инкре- 
ментного наращивания границ или объема тестирования. Если 
планирование было проведено качественно (см. главы 6 и 7), участники 
проекта не удивятся такому развитию событий. 

Иногда можно обнаружить большие новые области рисков, которые 
влекут за собой существенные изменения в границах тестирования. Пред- 
положим, что спецификация архитектуры для продукта Зрееду\Мгкег по- 
казывает, что система должна работать не только в интранете компании, 
но и в Интернете как система АЅР (поставщик услуг по аренде приложе- 
ний, модель АЗР (АррНсаНоп Ѕегуісе Ргоуійег) — концепция аренды при- 
ложений с размещением всей серверной инфраструктуры у провайдера 
этих услуг). Хотя это не входит в перечень требований к продукту для го- 
товящейся версии, системный проектировщик принял решение, что 
пора технически готовить систему к этому. В результате необходимо до- 
бавить новые области тестирования, в том числе медленные коммутируе- 
мые (Чіаї-цр) соединения, а также обновить задачи тестирования в неко- 
торых ранее включенных областях, это может быть, например, проверка 
совместимости и безопасности браузеров. 

Вероятность риска может изменяться не только при обнаружении но- 
вых рисков, но и в результате его возрастания в тех областях системы, ко- 
торые, казалось бы, уже исследованы. В качестве примера приведу случай 
из моей практики. В одном из проектов было довольно поздно обнаруже- 
но, что ранее согласованное с одним из поставщиков подсистем тестиро- 
вание производительности не проводилось. Я обнаружил это упущение, 
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когда выполнял трассировку тестового покрытия относительно рисков 
качества (см. главы 10 и 11). Эта находка позволила проектной группеуве- 
личить объем тестирования, проверяющего риски, связанные с произво- 
дительностью системы, в рамках фаз комплексного и системного тести- 
рования. Конечно, было бы лучше, если бы этого упущения не было 
вовсе, однако анализ рисков качества предоставляет нам инструмент, по- 
зволяющий учесть и такое изменение. 

В конечном счете, любое изменение требует пересмотра соглашений 
о функциональности, качестве, сроках и бюджете, присущих разработке 
любой системы. Эффективные группы управления проектом знают, как 
при получении новых сведений использовать возможности для пересмот- 
ра решений. Имея больше информации, можно принимать более успеш- 
ные решения. Я работаю над процессами, которые позволят поддержи- 
вать непрерывное совершенствование понимания системы. Группы 
управления изменениями часто становятся частью такого процесса и ор- 
ганизуют форум для открытых дискуссий и поиска компромиссов по по- 
воду ранее принятых решений. 

В некоторых компаниях нет такого способа организации сотрудни- 
ков. В этом случае можно использовать регулярные обновления докумен- 
та с описанием анализа рисков качества параллельно с проведением обзо- 
ров изменений совместно с заинтересованными лицами. Если с их 
стороны вы чувствуете поддержку, планируйте совещания по достиже- 
нии основных рубежей проекта. Это также будет способствовать более ка- 
чественной работе группы тестирования, координирующей принятие ре- 
шений при отсутствии структуры, управляющей обсуждением, хотя 
тестировщики могут по-прежнему получать существенную отдачу от про- 
цесса анализа рисков качества и последующих обновлений итогов этого 
анализа. 

Считаю, что необходимо быть предельно внимательным к организа- 
ционным, функциональным, технологическим и проектным изменениям 
и принимать в расчет любые дополнительные знания о проекте, которые 
оказывают воздействие на риски качества. Также надо быть готовым к уп- 
реждающим мерам в случае возникновения изменений. Я отдаю себе от- 
чет в том, что делать работу по управлению рисками качества более эф- 
фективной означает реагировать на изменения, а не рассматривать их 
как ужасные обстоятельства. 


Решение проблем 


До начала внедрения анализа рисков качества в компании необходимо 
принять ряд решений и подготовить ряд мероприятий по преодолению 
препятствий, с которыми наверняка придется столкнуться. 


Реальная оценка рисков 


Риск — это понятие, которое многие считают знакомым, но редко 
умеют с ним рационально работать. Некоторые люди, не задумываясь, 
водят каждый день машину, но боятся погибнуть в авиакатастрофе, хотя 
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из-за автомобильных аварий гибнет в сотни раз больше людей. Попытки 
законодательно исключить существование рисков продолжают делать 
правительства многих стран мира, принимая огромные бесполезные 
усилия во имя минимальных сокращений вероятности рисков. Обычно 
в школах и колледжах учащиеся не уделяют много внимания вероятно- 
сти, статистике и рискам, если они не обучаются математике, бизнесу, 
инвестициям или страхованию. Лишь очень немногие журналисты в со- 
стоянии разъяснить читателям суть риска в статьях, которые затрагива- 
ют рассматриваемую тему. Я стал понимать степени риска в моей жизни 
и эффективно управлять ими только тогда, когда изучил риски и стати- 
стику. 

Неспособность рационально работать с рисками может вызвать пр 
блемы в проектах разработки, сопровождения и поставки системы. Как- 
то одна тест-менеджер сказала мне, что она испытывает трудности при 
объяснении своим менеджерам рисков качества системы. В ходе двух про- 
ектов разработки она предупреждала их о серьезных упущениях в покры- 
тии тестами и говорила о возможном отрицательном эффекте, который 
может быть произведен на заказчика по причине наличия ошибок в этих 
областях. После выпуска версий, когда этих ошибок не обнаруживалось, 
менеджеры говорили ей: “Посмотрите, в конце концов риск не был столь 
велик”. Она сказала мне, что просто сбита с толку и начинает думать, что 
они правы. 

Не сомневаюсь, что иногда менеджеры проектов правы, делая такого. 
рода заявления. Но иногда им просто везет. Иногда очень везет. Но везе- 
ние не может повторяться всегда. 

Обманчивая сторона риска состоит в том, что, когда мы пытаемся за- 
глянуть в будущее, существует некоторая статистическая вероятность 
того, что нежелательное событие произойдет. Точное значение этой ве- 
роятности, расположенное где-то между нулем и единицей, обычно неиз- 
вестно. Когда мы оглядываемся в прошлое, нежелательное событие либо 
произошло, либо не произошло. Вероятности событий в прошлом либо 
равны нулю, либо равны единице. Выводы об уровнях рисков на основе 
небольшого числа удачных исходов означают попытку выдать желаемое 
за действительное, когда идет речь о способе проявления риска. История 
индустрии программирования слишком богата погибшими компаниями 
(например, когда-то в секторе баз данных для персональных компьюте- 
ров доминировала компания А$оп-Та(е), чтобы пренебрегать опасны- 
ми рисками. 

Полезно понимать, что ожидание принятия рациональных решений 
по рискам от всех участников проекта — это ожидание чересчур многого. 
При принятии решений по рискам добавляется большое число иррацио- 


і Две отличные, практичные и нетехнические книги о рисках: Питер Бернстайн (Регег 
Вегизісіп) "Араїпзі ће Сод и Джеймс Уолш (]атез У/аїізі) “Тгие 0421. В этих книгах нет ниче- 
го о системном тестировании, но они помогли мне понять риски и, как следствие, смысл 
моей работы. Полезными также могут оказаться большинство учебников по статистике для 
колледжей. 


З Интересная статья об этом политическом ракурсе “Тһе Віз іп Віз Мападетепи", напи- 
санная Питером де Ягером (Реїег Фе ]аевег), появилась в журнале “ойша Тезііпрата Оцайту 
Епріпеетітр", Уоїате 3, Ізѕие 4 (Ји Аму 2001). 
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нальных факторов. Если какой-то риск кажется пугающим и последствия 
проявляются немедленно или в ближайшей перспективе или известно о 
чужом опыте, когда была заплачена высокая цена за этот риск, люди пыта- 
ются всеми силами избежать его, даже если на самом деле вероятность и 
влияние риска не требуют этого. И наоборот, если людям кажется, что 
они держат риск под контролем, если это риск, который они выбрали соз- 
нательно (и оценили рационально), если возможные последствия нахо- 
дятся где-то в отдаленном будущем или если аналогичные риски уже были 
и не оказали отрицательного эффекта, эти риски принимаются с боль- 
шим энтузиазмом, нежели диктует логика . 

Тестировщики-профессионалы имеют в своем арсенале множество пу- 
гающих рассказов о том, как решения о выборе того или иного риска при- 
водили к полной катастрофе. Следовательно, по причинам и рациональ- 
ного, и иррационального характера можно сделать вывод о том, что 
тестировщики имеют склонность сильно преувеличивать опасность рис- 
ков. Я встречал тестировщиков, которые предупреждали об определен- 
ных “любимых” рисках качества на протяжении многих проектов. При- 
чем во всех проектах их менеджеры вновь и вновь игнорировали эти 
предупреждения. Верным решением было не тратить время на обсужде- 
ние этих рисков. На протяжении десятков или около того версий пробле- 
мы, относящиеся к этим рискам качества, ни разу не проявлялись. Тести- 
ровщики наверняка просто переоценили вероятность этих рисков 
качества. 

Однако компания, занимающаяся, например, электронной коммер- 
цией и решившая не проводить тестирования нагрузки и безопасности 
своего међ-сайта, с большой вероятностью будет нести убытки, посколь- 
ку не позаботилась о снижении влияния рисков в этих областях. Компе- 
тентные менеджеры разработки, сопровождения и поставки системы 
умеют эффективно управлять рисками, которые имеют существенное 
значение для недопущения финансовых потерь компании, а иногдаи ее 
гибели. Тест-менеджер отвечает за получение реалистичных оценок 
рисков качества, включая потенциальные потери, перед группой управ- 
ления проектом. 


Многообразие источников рисков качества 


В рассматриваемом примере Джамал и группа специалистов разного про- 
филя считают все риски качества относящимися к природе разрабаты- 
ваемой системы. Они начинают с анализа перечня различных категорий 
проблем, присущих системам, а затем конкретизируют виды ошибок 
в рамках этих категорий. Другими словами, участники анализа обследуют 
риски качества, которые возникают из контекста системы, поскольку они 
реализуют функциональность с помощью некоторых технологий на от- 
дельно взятой архитектуре аппаратного и программного обеспечения, 


й Для дальнейшего изучения темы смотрите отменную презентацию Эрика Симмона (Егік 
5шатоп) “Тһе Нитап $4е ої В1зК”, впервые опубликованную в “Тйе. Ргосее4 тру оў Ше 
Іпіетайопа! Еійеєпій Іпієтеї ата 5о/їшате Фив УТ 2007 и размещенную в настоящее время 
на сайте муукуг.гехбіасксопаційня сот. 
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а не, скажем, в соединительных проводах и ячейках, в наборе шестере- 
нок, пластмассе и древесине". | 

Однако наряду с рисками качества, связанными с самой системой, су- 
ществуют риски качества, связанные с проектом, процессом и даже орга- 
низационным устройством группы проекта, которая разрабатывает сис- 
тему. Например, предположим, что требования продолжают изменяться 
почти до даты выпуска проекта. Лично я стараюсь учесть эти виды рисков 
при планировании процесса тестирования (см. главы б и 7). Вто жевремя 
для снижения этих рисков можно использовать метод анализа видов оши- 
бок и их влияния или какой-либо другой метод анализа рисков. В книге 
"Кайите Моде апа Ебесі Апаіузії Стаматис рассматривает применение этой 
методики к рискам качества, относящимся к процессу. 


Кто управляет анализом рисков качества? 


Анализ рисков качества, описанный в этой главе, является мощным инст- 
рументом. Как уже упоминалось ранее, сила этого инструмента в большой 
степени зависит от привлечения к анализу специалистов разного профи- 
ля. Действительно, многие методы оценки качества включают в себя 
сложные обсуждения, выходящие за организационные пределы проекта 
и концентрирующие внимание ключевых заинтересованных лиц на кон- 
кретных проблемах. Однако слишком многопрофильная природа таких 
процессов и широкий охват специалистов и руководителей могут выну- 
дить людей задуматься о том, кто должен инициировать процессы и со- 
действовать их успешному осуществлению. Ответ на этот вопрос зависит 
от ситуации. Возможно, вы работаете в компании с формализованным 
процессом разработки и с группой контроля качества, задачей которой 
является контроль всего процесса и качества системы в целом. В этом слу-. 
чае анализ рисков качества, вероятно, находится в сфере ответственно- 
сти какого-либо сотрудника группы качества. 

В своей книге "5о/їшате Рүојесі бити Сша Стив Макконнел (Ѕгеуе 
МсСоппе!) исследует управление рисками в самом широком смысле. Оно 
направлено на выявление и снижение значительных рисков, угрожаю- 
щих разработке или сопровождению системы. Макконнел рекомендует, 
чтобы в каждом проекте был назначен сотрудник, отвечающий за выявле- 
ние, расстановку приоритетов и корректное смягчение рисков . В таких 
случаях ответственный за риски, очевидно, будет управлять анализом 
рисков качества. 

По моим НН обычно группа тестирования берет управле- 
ние процессом анализа рисков качества в свои руки. Поскольку процесс 
наиболее эффективен только при привлечении специалистов разного 
профиля, это может иметь серьезные технические, персональные и по- 


1 В музее искусства и наук в Париже есть интересная коллекция механических вычисли- 


тельных устройств, включая абак, экземпляры аналитической машины Беббиджа и лога- 
рифмической линейки. Увидев этиустройства, я подумал о том, как бы я стал проводитьтес- 
тирование на них. Затем, я начал размышлять, как повлияет на тестирование новый скачок 
в компьютерных технологиях (например, изобретение квантового компьютера). 


2 Ом. "Ѕойшат Рюјес Зитоний Сигаг", с. 98—101. 
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литические последствия для тестировщика, который инициирует анализ 
рисков качества и способствует его проведению. 
`На техническом уровне этот человек должен обладать соответствую- 

щими навыками в использовании выбранной методики. Неформальные 
методы наиболее просты и, вероятно, являются наилучшим вариантом 
для новичка, особенно в случае, когда процесс разработки не слишком 
формализован. Если есть ощущение, что нужно апробировать более 
сложные методы: анализ видов ошибок и их влияния, Т-МАР или І5О 
9126, я бы рекомендовал внимательно прочесть материалы, на которые 
приведены ссылки в разделе “Выбор подходящей методики” (см. выше). 
Возможно, вы также захотите подготовить краткое изложение методики 
для других участников. 

Ответственный за проведение анализа рисков качества должен иметь 
в своем арсенале более простые методы управления коллективом, вклю- 
чая мозговой штурм, разрешение конфликтов, следование повестке дня и 
графику и т.п. Наиболее опытные менеджеры со временем приобретают 
эти навыки, поэтому, еслиу вас не было случая научиться всему этому, для 
начала ознакомьтесь хотя бы с идеями. Продолжительные сложные дис- 
куссии, подобные тем, которые возникают в ходе анализа рисков качест- 
ва, требуют постоянного совершенствования навыков управления. 

Кроме того, тестировщик, ведущий совещание по вопросам рисков ка- 
чества, должен обладать доверием и политической поддержкой. Если по 
каким-либо причинам вы чувствуете, что не имеете достаточного влия- 
ния для ведения совещания, в котором участвуют приглашенные высоко- 
поставленные менеджеры, попытайтесь заручиться поддержкой своего 
менеджера или привлечь опытного консультанта либо для помощи, либо 
для проведения совещания. Если вы ввязались в процесс и устроили из 
него бессмысленную болтовню, в результате чего бесполезно расходуется 
рабочее время участников, совещание выходит из-под контроля и не при- 
носит полезных результатов, то вы можете нанести непоправимый ущерб 
как доверию, так и вашему политическому влиянию. 


Исключение магии из количественных оценок рисков 


Британский'ученый лорд Кельвин однажды писал, что без количествен- 
ных оценок нет настоящего знания. Хотя будет логической ошибкой при 
рассмотрении обратного утверждения считать, что, приспособив неко- 
торый способ измерения к атрибуту, можно получить глубокое представ- 
ление о его внутреннем устройстве. Числа и метрики сами по себе не соз- 
дают, помимо точности модели, никаких волшебных способностей у их 
пользователей. | 

В таких методах, как анализ видов ошибок и их влияния и метод стои- 
мости обнаружения проблем, я получаю значения приоритетов рисков и 
затем использую их для принятия решений о тестировании. Эти значе- 
ния помогают упорядочить множество всех выявленных рисков. Други- 
ми словами, я получаю представление об относительном значении каждо- 
го риска. На рис. 2.2 можно видеть, что идентификаторы рисков 1002, 
1003, 1004 и 1005 выстроены в порядке убывания значений приоритетов 
рисков: 3, 9, 27 и 81 соответственно. 
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Однако, если скрыть значения приоритетов рисков, становится трудно 
сделать какие-либо выводы. Компоненты значений приоритетов рисков, 
в особенности оценки приоритетов бизнеса и вероятности, основываются 
большей частью на опыте, интуиции и профессиональных знаниях. Даже 
значения вероятности, предмета актуарного анализа, редко основаны на 
статистически проверенных данных, собранных на большом числе проек- 
тов. Даже если бы у нас и были такие данные, из-за принципиальной новиз- 
ны каждого проекта экстраполяция может применяться лишь ограничен- 
но. Страховые компании экстраполируют риски, связанные с курением 
сигарет, на другие формы потребления табака, например курение сигар. 
Однако мы не можем экстраполировать виды ошибок, наблюдаемые при 
клиент-серверной реализации системы, на уровни риска при реализации 
той же системы как уеб-приложения. 

Практический результат состоит в том, что количественные оценки 
рисков, несмотря на полезные модели упорядочения рисков, остаются 
неточными приближениями. Предусмотрительные тестировщики долж- 
ны убедиться в том, что другие заинтересованные лица, особенно впер- 
вые применяющие методику, понимают ограничения, связанные с ис- 
пользованием количественных оценок. Если выуслышите, что участники 
процесса связывают точные ожидания с применением методов управле- 
ния рисками, например: “Если мы снизим все риски, имеющие приори- 
тет, равный 30 и ниже, за счет тестирования на всех фазах, мы уменьшим 
потери от низкого качества в данной версии на 37.5%”, — не сомневай- 
тесь, что нужно потратить время и усилия на то, чтобы убедить таких лю- 
дей, что не стоит ожидать чудес от количественных оценок. 

Наконец убедитесь, что вы сами не жертвуете пониманием проблем 
в пользу магии чисел. Я уже показал на примерах, каков должен быть объ- 
ем тестирования, если он управляется значениями приоритетов рисков. 
В реальности мне часто приходится тестировать некоторые риски более 
тщательно, поскольку, исходя из моего опыта, это разумно, в то время как 
их значения приоритетов показывают, что эти риски менее опасны, чем 
другие. Рассмотренные количественные методы являются полезными, 
если их применять осмотрительно и с достаточной гибкостью. 


Как работать с вариациями значений оценок 


До определенной степени оценка рисков зависит от субъективного взгляда, 
от суждений участников анализа. В методе анализа видов ошибок и их влия- 
ния серьезность потенциальной проблемы обычно очевидна, что в мень- 
щей степени относится к приоритету и вероятности. Ценность числового 
значения, для которого существуют проблемы субъективности и индивиду- 
альной оценки, снижается, ‘если заинтересованные лица соглашаются 
с оценкой. Если относительно определенного риска с низким приоритетом 
достигается консенсус, маловероятно, что этот прогноз будет точным, если 
считать, что участники проинформированы о консенсусе. 

С другой стороны, предположим, что заинтересованные лица не со- 
гласны с субъективной шкалой. Широкий разброс в оценках, полученных 
от разных участников, позволяет сделать предположение об отсутствии 
точности в оценках. Иначе говоря, среднее значение при разбросе деся- 
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ти оценок от 1 до 5 мало что дает, если стандартное отклонение этих оце- 
нок велико. 

Например, представим, что десять человек участвуют в оценке при- 
оритета риска по шкале от 1 до 5. Двое участников оценили риск как 1, 
двое других — как 2, двое — 3, двое — 4 иеще двое — 5. Среднее значение 
равно`3, но стандартное отклонение равно 1.5. Из полученных данных 
очевидно, что консенсуса по данному риску не достигнуто. Среднее значе- 
ние может лишь только привести к заблуждению относительно реальной 
ситуации. Даже если получено множество значений, близких к статисти- 
ческому идеалу нормального распределения, например {1, 2, 2, 3, 3, 3, 3, 
4,4, 5}, по-прежнему есть шесть человек, не согласных с оценкой 3, а стан- 
дартное отклонение примерно равно 1.2. 

Я часто замечал, что, когда возникают расхождения в оценке приори- 
тета, заинтересованные лица представляют интересы разных групп за- 
казчиков и пользователей. Например, продвинутые пользователи могут 
считать важными свойства приложения, связанные с использованием 
макросов, в то время как остальные пользователи никогда не обратятся к 
этим свойствам. Оценка числа и значения для компании определенного 
заказчика или групп пользователей, для которых значимо то или иное 
свойство приложения или которые являются предметом определенного 
риска, может способствовать нахождению определенного компромисса 
по вопросу приоритета свойств. Еще одна причина различия в оценках 
может заключаться в том, что некоторые заинтересованные лица неучли 
при рассмотрении какие-либо важные соображения. В этом случае поис- 
ку консенсуса может помочь открытая дискуссия о том, почему люди вы- 
брали ту или иную оценку. 

Для вероятности также полезным соображением является сегменти- 
рование групп заказчиков и пользователей по принципу: кто использует 
свойства или какому риску подвергается. Оценка вероятности должна 
быть единой для всех пользователей. Если какое-то предположение ока- 
зывается верным лишь для очень малой группы пользователей, но этот 
сегмент пользователей очень важен для долгосрочной стратегии компа- 
нии, нужно увеличить значение приоритета, а не фабриковать значение 
вероятности. 

Еще одно соображение по поводу вероятности касается техническо- 
го риска. Какова вероятность внесения дефекта? Здесь ведущую роль 
должны сыграть заинтересованные лица, являющиеся специалистами в 
технологических вопросах, с учетом наличия у них соответствующих 
знаний и опыта. Когда люди строят новые системы на основе новых тех- 
нологий, решающих задачи новыми способами, обычно число участни- 
ков, которые могут похвастаться соответствующим опытом, невелико. 
В результате оценки технических рисков могут основываться на личном 
уровне оптимизма и неприятия риска. В этих случаях я пытаюсь понять, 
на чем основана оценка вероятности: на опыте или на догадках. Если 
она основана на догадках, то при оценке рисков получается определен- 
ный разброс оценок вероятности и разброс значений приоритета рис- 
ка. Можно посоветовать группе управления проектом отдельно провес- 
ти оценку для некоторых рисков, а затем дать ей возможность сделать 
запрос. 


Глава 2. Основа успеха 63 


Как убедить заинтересованных лиц в принятии реальности 


Когдавы впервые проводите анализ рисков качества, возможно, люди от- 
кликнутся с энтузиазмом, однако энтузиазм может иссякнуть, если станет 
очевидным объем затрат. Формальный подход к оценке рисков качества 
требует существенных затрат времени, а следовательно, и денег. Даже не- 
формальный подход потребует затрат какого-то времени от каждого уча- 
стника, | , 

Вероятно, важно и то, что процесс анализа требует готовности каждо- 
го из заинтересованных лиц зафиксировать решения, которые не всегда 
совпадают с их мнением. Они должны подходить к задаче с пониманием 
реалий разработки, сопровождения и поставки системы сучетом ограни- 
чений по бюджету, срокам, качеству и перечню свойств системы. Ожида- 
ния систем с нулевым риском или со 100%-ным снижением рисков за счет 
тестирования являются нереалистичными, но любая компания способна 
улучшить работу поуправлению рисками качества систем, которые разра- 
батываются, сопровождаются или поставляются. 

Неудовлетворенность текущим состоянием дел — это один из мощ- 
нейших инструментов, имеющихся в распоряжении тестировщика. 
Считается ли, что в компании отлично обстоят дела с продажами, мар- 
кетингом и поддержкой пользователей? Если да, то организация про- 
цесса анализа рисков качества может оказаться весьма непростой. Од- 
нако чаще всего люди знают, что компания может работать лучше. Но 
сотрудники, не связанные с технологиями, должны также понимать, 
что проблемы существуют не потому, что люди в производственных 
подразделениях компании ленивы или умышленно плохо выполняют 
свои обязанности, а потому, что процессы и навыки сотрудников этих 
подразделений нуждаются в усовершенствованим . Анализ рисков ка- 
чества — это одно из направлений усовершенствования процесса, кото- 
рое может оказаться полезным. 


Внедрение усовершенствований 


Итак, мы выбираем методику анализа рисков качества как основу для сле- 
дующего шага. Вот несколько идей о том, как начать эту работу. 


1. Исследуйте категории рисков качества. Начните с изучения катего- 
рий, которые подходят для вашей системы. Выше были представле- 
ны четыре книги, которые могут быть хорошими начальными по- 
собиями. Также полезные идеи по поводу технических рисков 
можно найти в различных книгах по проектированию и реализа- 
ции данного вида систем, например клиент-серверных систем или 
систем на основе међ-технологий. ' 


2. Определите ключевых заинтересованных лиц. Кто отвечает за ка- 
чество и тестирование? Используя представление о структуре ком- 


Другие заблуждения руководства по поводу понимания ограничений возможностей про- 
цессов из-за лености персонала, в том числе классическое упражнение с черными и красны- 
ми бусинами, описаны в "Оці о/ йе Стізіз", МГ. Е. решіпо. 
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пании и таблицу 2.2, вы должны определить сотрудников, чье уча- 
стие необходимо. 


3. Уговорите заинтересованных лиц заняться управлением рисками ка- 
чества. Вооружившись некоторыми идеями по поводу того, каким 
образом система может вести себя некорректно, а также перечнем 
людей, которые, как вы полагаете, заботятся о качестве системы, 
‘можно найти ключевых заинтересованных лиц и рассказать им о ва- 
ших соображениях. Помогите им понять, как управление рисками 
качества может способствовать тому, что будет проведено тестиро- 
вание только тех частей системы, которые существенны для выпуска. 
версии. Проинформируйте их о процессе. Укажите на то, что про- 
цесс направлен на достижение разумных компромиссов относитель- 
но различных областей риска — сроков, бюджета, перечня реализуе- 
мых свойств и качества — и различных категорий рисков качества. 


4. Выстраивайте процесс анализа рисков качества. Заручившись под- 
держкой заинтересованных лиц и имея на руках идеи о существую- 
щих рисках, начинайте анализ рисков качества. Если в компании 
пока нет выстроенных процессов, попытайтесь начать с какого- 
либо из неформальных методов. Если вы уже используете нефор- 
мальный метод, попробуйте перейти к одному из формальных ме- 
тодов. Чтобы обеспечить поддержку процесса, не усложняйте его. 


5. Используйте оценку рисков для распределения ресурсов. В рассматри- 
ваемом примере Джамал и его коллеги распределили уровни тестиро- 
‚ вания по значениям приоритетов рисков, полученным в результате 
применения ЕМЕА. Можно также применять качественные оценки, 
если вы видите, что это более соответствует ситуации. Покрытие оп- 
ределенного риска качества не является выбором между полным ва- 
риантом и отсутствием покрытия. Различные уровни тестирования — 
это точки на непрерывной шкале. Основная идея состоит в примене- 
нии уровня риска в качестве основы для оценки времени и ресурсов, 
выделяемых на тестирование в любой данной области системы. 


По мере внедрения всех этих новшеств при проведении тестирования 
вы начинаете разговаривать на языке рисков. Говорите о тестировании в 
терминах рисков и управления рисками. Вы обнаружите, что при обсужде- 
нии тестирования в этой манере вас хорошо понимают и принимают ваши 
доводы. Управление рисками — популярная тема. Менеджеры понимают 
управление рисками интуитивно, даже если они незнакомы с формальным 
введением в это понятие. Я заметил, что даже менеджеры высшего звена, 
которые имеют ограниченное представление о тестировании; понимают, 
что я имею в виду, если я говорю об управлении рисками качества системы. 
Это не просто звучит разумно, управление рисками качества является ра- 
зумным само по себе. 


ГЛАВА 3 


Внутри хрустального шара: 
оценка предстоящей работы 


| | осле завершения анализа рисков качества, описанного в предыду- 

щей главе, мы знаем, что нужнотестировать. Мы понимаем, какие 
риски качества системы угрожают уснеху проекта, и их относительную 
значимость. Это понимание невозможно переоценить, поскольку без 
него тестирование не будет управляться качеством и может легко пре- 
вратиться в безрассудную трату времени, денег и сил программиста, вве- 
сти в заблуждение руководство и доставить ему лишние заботы. Чтобы 
правильно ориентировать подпроект тестирования, необходимо адек- 
ватно покрывать эти риски с помощью грамотно спроектированных 
тестовых сценариев. Я вернусь к этой теме в главах 10 и 11, в которых 
рассматриваются проектирование и разработка тестовых сценариев, 
тестовых данных, инструментов тестирования и другие компоненты 
системы тестов. 

Но я бы пропустил некоторые важные этапы, если бы начал уже сей- 
час проектировать и разрабатывать систему тестов. По завершении ана- 
лиза рисков качества я знаю, какие риски угрожают качеству системы. Од- 
нако в успешных проектах рабочая группа находит баланс между 
качеством, свойствами системы, бюджетом и сроками. Если принять, что 
итоги анализа рисков качества высечены из камня, и объявить, что все ре- 
комендованные действия группы тестирования должны быть выполнены 
и каждый риск качества с высоким приоритетом должен быть покрыт 
системой тестов, можно неприемлемо увеличить риски для свойств, бюд- 
жета и сроков. Например, если требуется слишком много времени, чтобы 
завершить все тестирование в проекте, проект выйдет за границы бюдже- 
та и сроков. 

_ В этой и следующих двух главах рассматривается процесс оценки ре- 
сурсов. Процесс оценки ресурсов описывает механизм, с помощью кото- 
рого тестирование встраивается в рамки сроков и бюджета проекта. 
В ходе процесса осуществляется переход от решения вопроса “что нуж- 
но тестировать” к решению вопроса “что я могу протестировать” в рам- 
ках проекта. В ходе этого процесса часто приходится удалять определен- 
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ные активности, задачи и ресурсы из рамок подпроекта тестирования 
из-за их стоимости. Выбирая объект для удаления, можно опираться на 
иерархию рисков, выстроенную в ходе анализа. Она служит в качестве 
сети для отбора наиболее важных рисков качества и отбрасывания наи- 
менее важных. 

Оценка ресурсов — это объемный процесс, требующий напряжения 
сил. Он хорошо заметен в компании, особенно если выполнен слабо, 
и оказывает значительное влияние на способности группы тестирования 
выполнять свою миссию в проекте. Это также процесс, который многие, 
в том числе и я, считают сложным. Довольно легко соорудить сносно вы- 
глядящий график Гантта, используя коммерческие версии программного 


обеспечения для управления проектами. Однако если отвлечься, можно 


Это упрощенный автором вариант определения из предисловия к “Тйе Сшае іо іће Ргојесі 
Мапаретепі Воду оў Кпоилеаре”, 2000 Едіцоп, ммгм.риаї ого. 
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понять, что нам нужны реалистичные, работоспособные и честные оцен- 
ки. Давайте изучим, как можно создавать такие оценки. 


Процесс оценки затрат 


Процесс оценки затрат, представленный в Процессе 4, разбит на 5 основ- 
ных зтапов, каждый из который имеет несколько подэтапов. В рамках 
этапов и подэтапов допускается любое число итераций. Поскольку оцен- 
ка затрат — это сложный и ключевой процесс, в этой главе рассматривает- 
ся первый этап, этап 2 - в главе 4, а этапы 3 — 5 описываются в главе 5. 

С чисто механистической точки зрения, составление декомпозиции 
работ на первом этапе не будет сложной, если использовать программы 
для управления проектами. Инструмент управления проектом генериру- 
ет красивые графики Гантта и сетевые диаграммы, но это не означает, 
что их пользователь сможет понять, что будет происходить дальше. Ко- 
нечно, нужно уметь пользоваться программным обеспечением для 
управления проектом, но в действительности необходимо уметь загля- 
нуть в будущее. 

При декомпозиции работ важно знать, когда остановиться при выде- 
лении действий, задач и подзадач. В хорошо согласованной декомпози- 
ции работ для подпроекта тестирования каждая задача на самом нижнем 
уровне обладает следующими характеристиками: 


1. Измеряемое состояние 
2. Четко сформулированные критерии начала и завершения 


3. Один или более исходящих и, возможно, входящий передаваемый‘ 
материал 


4. Оценка требований к ресурсам, объему выполняемых работ, их 
продолжительности и другим затратам 


5. Короткая продолжительность 


6. Независимость (после того как выполнен критерий начала) от дру- 
гих задач в рамках и вне подпроекта тестирования 


7. Четко выделенный ответственный исполнитель, в идеале — один 
человек 


8. Отображение выявленных в ходе анализа рисков качества на одну 
или более рекомендуемых работ по тестированию (причем все 
фазы, активности и задачи, взятые вместе, покрывают все рекомен- 
дуемые работы по тестированию) | 


9. Место задачи в перечне работ основано на приоритетах рисков на- 
столько, насколько это позволяют взаимозависимости задач и огра- 
ничения по ресурсам 


1 Фрагменты этой и последующих двух глав впервые были опубликованы в статье “Тез 
Езіітагцоап" в "Зо/їшате Тезіїпу апа Оиаійу Епріпеєтіто", Уоїште 4, Іззие 6 (Моу/ Пес 2009), 
а также в “Еасгогѕ Тһаї І иерсе Тез Еѕітайоп” на уму. НсКуш!а5.сот и мулу. гехБіаск- 
сопзшіпр.сот. Благодарю за редакторскую помощь Эстер Дайсон (Езіћег Оузоп) и Ро- 
берта Кутре (Кобегі Сошге). 


Часть І. Планирование 


Процесс 4. Оценка 


№ этапа Этап. Выполнено? 


1. 


1А 


ів 


1.С 


1р 


1Е 


1Е 


1.6 


2А 


2.В 


2.С 


Работая в одиночку или совместно с приданной группой тес: о 
тирования, вьшолнить декомпозицию и составить план работ. 


Разбивка проекта на фазы. п 


Разбивка каждой из фаз на составляющие ее активности (дей- п 
ствия). 


Разбивка каждой активности на задачи и подзадачи, пока каж- п 
дая задача и подзадача на низшем уровне декомпозиции не бу- 
дутудовлетворять критериям, перечисленным ниже. 


Определение зависимостей, распределение ресурсов и зави- 0 
симых задач в рамках подпроекта тестирования с учетом при: 

оритетов рисков. Документирование зависимостей, ресурсов 

и задач, внешних по отношению к подпроекту тестирования 

(т.е. требующих совместных действий). 


Проверка, с точки зрения здравого смысла, длительности О 
и объема работ на уровне каждой задачи, подзадачи, активно- 

сти и фазы. По возможности сопоставить профессиональные 

знания и интуицию с данными предыдущих проектов, измере- 

ниями в отрасли и т.д. Выявить и, если возможно, разрешить 
расхождения между планами-графиками подпроекта тестиро- 

вания и самого проекта. Там, где это невозможно, документи- 

ровать проблемы. 


Проверка декомпозиции работ и плана-графика совместно с п 
сотрудниками, которые назначены ответственными за выпол- 

нение задач, с особым вниманием к выявлению любых пропу- 

щенных допущений и зависимостей. 


Рецензирование декомпозиции работ и плана-графика силами а 
всех сотрудников группы тестирования при участии экспер- 
тов в проблемной области как внутри, так и вне компании. 


Использовать декомпозицию работ и план-график для подго- а 
товки бюджета. 


Извлечение из декомпозиции работ полного списка ресурсов. п 
Определение для каждого ресурса первого и последнего дня 

работы в'проекте. В том случае, если есть ресурсы, занятые 

сразу в нескольких проектах, уточнить процентную загрузку 

каждого из таких ресурсов в каждом из проектов в течение 

различных периодов времени. 

Выявление необходимых дополнительных ресурсов для под- п 
держки ресурсов, занятых сразу в нескольких проектах. 


4 
Распределение ресурсов по категориям: персонал, команди- · а 
ровки, инструментарий, тестовая среда и, если есть, затраты 
на аутсорсинг. Суммирование по периодам времени и катего- 
риям. 
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Процесс 4 (продолжение) 


№ этапа Этап - - Вьшолнено? 


2.0 Проверка, с точки зрения здравого смысла, бюджета и общих с 
сумм. По возможности сопоставить профессиональные зна- Я 
ния и интуицию с данными предыдущих проектов, измерения- 
ми в отрасли и т.д., выявить и, если возможно, разрешить рас- 
хождения между бюджетом подпроекта тестирования и об- 
щим бюджетом проекта. Там, где это невозможно, документи- 
ровать проблемы. 


2.Е Уточнение амортизации объектов, которые являются пред- О 
метом долговременного инвестирования, документирова- 
ние возможностей их повторного использования и опреде- е 
ление периода, в течение которого планируется возместить 
затраты. 


2Е Если это необходимо или желательно, провести анализ воз- п 

врата инвестиций. Если сальдо отрицательное, проверить до- 
пущения об амортизации, сделанные на шаге 2.Е, и при необ- 
ходимости повторить:его. Если сальдо по-прежнему отрица- 

тельное, проанализировать те компоненты декомпозиции ра- 
бот, которые требуют наибольших затрат с наименьшей отда- 
чей, сверившись с рисками качества. Документировать актив- 

` ности, приводящие к потере средств. 


2.6 Если разрешено руководством, провести обсуждение бюджета О 
с группой тестирования. Особое внимание уделить выявле- 
нию всех пропущенных ресурсов, особенно дополнительных. 
При необходимости повторить этапы 2.0 ~ 2.Е. 


3. Утвердитьу руководства план-график и бюджет. г 
ЗА Презентация преимуществ подпроекта тестирования. а 
3.В Обрисовать временные и финансовые ресурсы, необходимые о 


для получения описанных преимуществ. 


3.С Осознание и принятие мер по разрешению любых возраже- 
ний по поводу сделанных оценок посредством повторения ша- 
гов 3.А и 3.В. 
3.0 Если не удается получить согласие руководства на предлагае- п 


мые план-график и бюджет, обсудить, какие области тестиро- 
вания могут быть исключены, установить, какие ограничения 


по срокам и бюджету позволят получить поддержку руково- 
дства. 


4. Повторить этапы 1 - 3, если необходимо. Уточнить график ЮО 
работ и бюджет с целью добиться адекватности ресурсов рам- 
кам тестирования (возможно уточненным) и одобрения руко- 
водства. - 


5. _ Поместить принятые документы, фиксирующие план-график 0 
и бюджет, в проектную библиотеку или систему управления 
конфигурацией проекта. Организовать контроль изменений 
документов. 
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Джамал предсказывает будущее 


По завершении семинара, посвященного анализу видов ошибок и их 
влияния, Джамал отправился на свое рабочее место и запустил приложе- 
ние по управлению проектом. Он также загрузил Зрееду\тиег 3.0, что- 
бы начать аккумулировать идеи относительно плана тестирования. Уви- 
дев перед собой два пустых шаблона, он на секунду впал в уныние, но 
затем принялся за работу. “Итак, — думал он, — какие фазы будут в этом 
проекте? Ну-ка, посмотрим: я должен подготовить план, мы собираемся 
написать кучу новых тестов, мне нужно попросить Кейта Ли и его группу 
системного администрирования настроить конфигурации некоторых 
новых систем в нашей тестовой лаборатории, а затем мы будем прово- 
дить комплексное и системное тестирование”. Он вписал эти фазы в де- 
композицию работ. 


№ этапа Этап Выполнено? 
1А Разбивка проекта на фазы. 


Фазу планирования оказалось легко конкретизировать. Джамал вме- 
сте с Дженни и Кейт Эрнандес уже выстроил контекст тестирования по- 
сле совещания, посвященного запуску проекта, а также начал анализиро- 
вать риски. После того как были сделаны оценки затрат, он приступил к 
подготовке плана тестирования. Джамал назначил себя ответственным за 
все задачи на фазе планирования, иначе говоря, он определил себя какре- 
сурс. Была обнаружена только одна зависимость: участие заинтересован- 
ных лиц, не входящих в группу тестирования; это было отмечено в черно- 
вом варианте плана тестирования. На рис. 3.1 показан план-график для 
этой фазы. 
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“Хм, — думал он, — когда же приступить к другим задачам?” Джамал ре- 
шил начать разработку с конца, с фазы выполнения тестов. Он будет отве- 
чать за системное тестирование. Посмотрев на план-график разработки, 
сделанный Дженни, он увидел, что планируемая дата поставки - 28 марта 
2003 г. Судя по предыдущим проектам, его группа должна завершить тес- 
тирование неделей раньше, чтобы можно было поставить “золотую сбор- 
ку” в производство. Таким образом, ориентировочная дата совещания по 
итогам системного тестирования - 21 марта 2003 г. К этому сроку система 
должна соответствовать критериям завершения тестирования, опреде- 
ленным в его плане тестирования. 
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Поскольку первый инкремент функциональности должен быть готов 
21 октября 2002 г., в этот день должно состояться совещание, посвящен- 
ное началу системного тестирования. Джамал знал, что к этому времени 
система должна отвечать критериям начала тестирования, определен- 
ным в плане тестирования. Также Джамалу было известно, что очеред- 
ные инкременты функциональности должны поступать на тестирование 


с четырехнедельным интервалом. Он добавил эти рубежи и события в 
план-график. 
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Джамал также отвечает за комплексное тестирование. Его необходи- 
мо завершить к 7 февраля 2003 г., когда последний инкремент с номером 
5 запланирован к поставке на тестирование. Джамал взял неделю до этой 
даты для проверки соответствия системы критериям завершения ком- 
плексного тестирования и для проведения заключительного совещания 
по этому вопросу. Начало интеграции модулей запланировано у Дженни 
на 30 сентября 2002 г. Джамал предположил, что группа тестирования 
сможет получить работоспособную версию для формального комплекс- 
ного тестирования 7 октября 2002 г. Он добавил эти контрольные точки и 
события в план-график. 

В рамках этих ограничений Джамалу необходимо включить несколько 
раундов и в каждом раунде по нескольку циклов для каждой фазы тестиро- 
вания. Это можно сделать с помощью программы составления графиков, 
но предыдущие попытки были неудачными для Джамала. Поскольку ему 
нравится работать с программами обработки таблиц для контроля вьшол- 
нения тестовых сценариев, он решил воспользоваться контрольной таб- 
лицей. На основе знаний рисков качества он мог бы набросать перечень 
тестовых сценариев, а также оценить время их выполнения. Затем он вос- 
пользовался бы полученными цифрами для определения длительности 
раундов при условии, что по тем или иным причинам некоторые из тесто- 
вых сценариев были пропущены в его черновом перечне. Джамал сделал 
допущение, что будет разработано дополнительно 50% тестовых сцена- 
риев, помимо ранее определенных им. Он остановился на этой цифре, 
исходя из опыта двух своих предыдущих проектов, в которых начальная 
оценка тестовых сценариев была соответственно на 30 и 60% меньше 
итогового числа тестовых сценариев при завершении системного тести- 
рования. 

Джамал исследовал по одному риски качества, сопоставляя с ними тес- 
товые сценарии и фиксируя информацию о покрытии тестами. Он также 
понимал, какие изтестовых сценариев будут выполняться без изменений, 
какие из них потребуют обновления, а какие должны быть написаны за- 
ново. Он стал собирать эту информацию для планирования фазы разра- 
ботки тестов. За основу оценки затрат на написание и обновление тесто- 
вых сценариев он взял предыдущий опыт, просматривая планы-графики 
своих двух последних проектов. 

Завершив первые грубые оценки, Джамал просмотрел краткий список 
комплектов тестов (см. рис. 3.2). Он добавил примерные трудозатраты в 
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Рис. 3.2. Оценка трудозатрат и продолжительности для тестовых 
сценариев, выполненная Джамалом 


человеко-часах на каждый тестовый сценарий, а также продолжитель- 
ность в обычных часах. И то и другое нужно для последующей оценки не- 
обходимого числа сотрудников и количества тестовых сред. 

Джамал провел вычисления и выяснил потребности в персонале и 
длительность выполнения тестового раунда в комплексном тестирова- 
нии, системном тестировании и продолжительность периода, когда 
фазы перекрывают друг друга (см. рис. 3.3). Он исключил тестирование 
локализации из своих расчетов числа необходимых тестировщиков, по- 
скольку планировал нанять внешних исполнителей для этого вида тести- 
рования, как это было при подготовке предыдущих версий. Для периода 
пиковой загрузки группы тестирования Джамал предусмотрел включе- 
ние двух специалистов по автоматизированному тестированию, одного 
специалиста по ручному тестированию и четырех младших тестировщи- 
ков. Поскольку каждые четыре недели будет повторяться комплексное 
тестирование, можно запланировать по одному полному четырехнедель- 
ному раунду комплексного тестирования на каждый инкремент. 

Для системного тестирования Джамал запланировал по два полных ра- 
унда на каждый инкремент, позаботившись о проведении регрессионно- 
го тестирования на случай, если сборки будут подвергаться частым изме- 
нениям. (Заметим, что Джамал, помимо исходной сборки, включающей 
функциональность инкремента, планирует получать версии с исправлен- 
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Рис. 3.3. Расчет необходимого числа сотрудников для перекрывающихся 
фаз тестирования 


ными дефектами в ходе тестирования каждого инкремента.) «Да, — думал 
он, — итерационный подход увеличивает период, когда обе фазы пере- 
крывают друг друга. При настоящей каскадной разработке мне нужно 
было всего три лаборанта, и готов поспорить, что мне хватило бы двоих. 
Однако при условии, что два младших тестировщика, работающих по 
контракту, обойдутся чуть дороже чем $75 000, по всей видимости, компа- 
нии выгодно их нанять, чтобы получить дополнительную гарантию успе- 
ха итерационного подхода к разработке». 


№ этапа Этап , Вынолнено? 
1.В Разбивка каждой из фаз на составляющие ее активности. | 

| [заполненный сһескЬох) 

1.С. Разбивка каждой активности на задачи и подзадачи, пока каж- 


дая задача и подзадача на низшем уровне декомпозиции не бу- 
дут удовлетворять нижеследующим критериям. 


Джамал заметил серьезную проблему с людскими ресурсами. Сначала 
он предполагал, что просто переведет в новый проект Эмму Мурхаус и 
Лин Цу Ву на роли специалистов по автоматизированному и ручному тес- 
тированию соответственно, так как они уже работали над версией 3.0 
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и сейчас занимаются ее сопровождением. Джамал хотел заполнить эти ва- 
кансии, используя их и еще двух опытных младших тестировщиков, кото- 
рые, как он полагал, уже готовы выполнять более ответственную работу 
как специалисты-тестировщики. Однако только Эммы и Лин Цу недоста: 
точно. Ему нужен еще инженер-тестировщик, поскольку, в противном 
случае, Лин Цу будет разрабатывать тесты до ноября, а Эмма еще доль- 
ше - до января. Это может поломать все планы по выполнению тестов, 
поскольку ни Эмма, ни Лин Цу не смогут руководить работой младших 
тестировщиков по выполнению тестов. Поэтому Джамал переработал 
часть планаграфика, относящуюся к разработке тестов, чтобы отразить 
добавление еще одного тестировщика. Он также дополнил план-график 
задачами по поиску и найму инженера-тестировщика и четырех младших 
тестировщиков, а также задачами по их обучению и вводу в проект. 

Получив первую серьезную оценку затрат, Джамал быстро проверил де- 
композицию работ относительно каждого из девяти критериев. Он обна- 
ружил проблемы, относящиеся только к распределению ресурсов, оценки 
для которых уже были получены, но еще нужно было уточнить их с участи- 
ем Эммы и Лин Цу. Воспользовавшись средствами построения графиков 
инструмента управления проектами и добавив вновь выявленные задачи, 
Джамал завершил первую часть оценки ресурсов. Еще остались проблемы с 
недозагрузкой и перезагрузкой ресурсов, но эти колебания присущи про- 
цессу выполнения тестов. В эти периоды у тест-менеджера есть определен- 
ная свобода в распределении нагрузки тестировщиков и всокращении пла- 
нового числа исполняемых тестов, если это необходимо. 


№ этапа Этап Выполнено? 


1р Определение зависимостей, распределение ресурсов и зави- М 
симых задач в рамках подпроекта тестирования с учетом при- 
оритетов рисков. Документирование зависимостей, ресурсов 
и задач, внешних по отношению к подпроекту тестирования 
(т.е. требующих совместных действий). 


Кроме того, некоторые из перекрывающихся работ являются резуль- 
татом неточностей при проведении оценок. Например, Эмма перезагру- 
жена в начальные периоды системного тестирования, поскольку она от- 
вечает и за выполнение, и за обновление скриптов для тестирования 
производительности и нагрузки. Однако, поскольку скрипты еще не бу- 
дут готовы к работе, ей придется заниматься только их обновлением. По- 
скольку Джамал помнил об этом при составлении плана-графика выпол- 
нения тестов, он понимал, что это не проблема при условии, что все 
заявленные тесты будут готовы к выполнению в порядке приоритетов 
рисков. 

Чтобы проверить эти два условия, Джамал вновь обратился к докумен- 
ту с анализом видов отибок и их влияния. Он проверил полноту покры- 
тия каждого риска, как это требуется в поле “Рекомендуемые действия”. 
Он также проверил, что задачи выстроены в соответствии с порядком 
приоритетов рисков там, где этот порядок может повлиять на возмож- 
ность выполнения тестов на определенных фазах. Пока было не совсем 
ясно, какие из свойств появятся в каких инкрементах и какие ошибки бу- 
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дуг исправлены. Однако Джамал подготовил ряд гипотез, как это должны 
делать все квалифицированные менеджеры. 

Джамал зафиксировал покрытие каждого риска качества тестовым сце- 
нарием на специальном листе в контрольной таблице. На основании реко- 
мендаций, данных в таблице метода анализа видов ошибок и их влияния, 
он принял решение об использовании модифицированной шкалы, приме- 
няемой в методе определения качества функциональности (см. главу 2): 


и 0 — тестовый сценарий не покрывает данный риск качества. 


и 1 — тестовый сценарий обеспечивает нероязнестноє покрьтие дан- 
ного риска качества. 


ш 3 - тестовый сценарий обеспечивает сбалансированное покрытие 
данного риска качества. 


и 9 — тестовый сценарий обеспечивает подробное покрытие данного 
риска качества. 


Помимо того, что данная информация дает уверенность в том, что ни- 
чего не пропущено, она имеет большое значение для подготовки отчета. 
Естественно, поскольку тестовые сценарии еще не написаны, Джамал сно- 
ва делает оценки. Теперь он оценивает, какие области, по его мнению, бу- 
дут покрывать тесты. В то же аде он проектирует тестовые сценарии с 
минимальной детализацией, исходя из своих представлений о том, что 
они должны покрывать. Данные оценки и результаты проектирования тес- 
тов необходимо будет проверить в ходе разработки системы тестов. 

_ В ходе отслеживания покрытия рисков Джамал обнаружил, что при 
проведении анализа видов ошибок и их влияния были пропущены два 
риска, связанных с интерфейсами. Помимо того, что клиент обращается 
к међ-серверу и уеб-сервер обращается к серверу баз данных, меЬ-сервер 
обращается к серверу приложений, а сервер приложений — к серверу 
управления иерархическим хранилищем. Джамал думал, что соответст- 
вующие риски имеются в таблице анализа видов ошибок и их влияния, 
и отправил электронное сообщение заинтересованным лицам с просьбой 
подтвердить свои подозрения. 

Чтобы проверить свою работу, Джамал просмотрел пару плановтрафи- 
ков и других документов из предыдущих проектов, отслеживающих выпол- 
ненную работу. Его оценки вписывались в представления о том, что проис- 
ходило в предыдущих проектах, по крайней мере, на верхнем уровне затрат 
на разработку автоматизированных тестовых сценариев и сценариев для 
ручного тестирования, а также человеко-часов на выполнение тестового ра- 
унда. Поскольку продолжительные фазы тестирования и их перекрытие яв- 
ляются неотъемлемой частью итерационного подхода к разработке систем, 
общая продолжительность тестирования в проекте и количество персонала 
оказалось существенно выше, примерно вдвое. 

Джамал также обратился к плану-графику разработки, подготовленно- 
му Дженни, и просмотрел распределение ресурсов. У нее было два проек- 
тировщика системы, два специалиста по пользовательским интерфейсам 
из группы Бобби, пять программистов на ]ауа, один эксперт по 5ОГ и ба- 
зам данных и один эксперт по мер-технологиям и приложению. 

Это означало соотношение тестировщиков и разработчиков 7 к 11. 
Джамалу известно, что при разработке коммерческих приложений это 
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соотношение обычно должно соответствовать среднему значению по от- 
расли. В то же время он понимал, что эти цифры существенно зависят от 
конкретной ситуации. 

Джамал уже почти готов перейти к следующему этапу — уточнению 
оценок с привлечением группы тестирования и других экспертов- 
тестировщиков компании 5оНугаге Сабетегіа. Во-первых, хотя он уже про- 
смотрел графики Дженни и Кейт и другие сведения на их интранет- 
сайтах, необходимо взглянуть еще раз, не забыл ли он что-то, не получил 
ли он график подпроекта тестирования, который не соответствует по- 
требностям проекта $реедуМтиег. В целом план выглядел неплохим, од- 
нако Джамалу все еще не было ясно, как альфа- и бета-версии для группы 
маркетинга могут повлиять на виды тестирования, за которые он отвеча- 
ет. Поскольку еще не существовало перечня ожидаемых свойств системы, 
он отправил сообщение Дженни и Кейт с просьбой организовать встре- 
чу, чтобы прояснить эту ситуацию. 


№ этапа Этап Выполнено? 


І.Е Проверка, с точки зрения здравого смысла, длительности и М 
объема работ науровне каждой задачи, подзадачи, активно- 
сти и фазы. По возможности сопоставить профессиональные 
знания и интуицию с данными предыдущих проектов, измере- 
ниями в отрасли и т.д. Выявить и, если возможно, разрешить 
расхождения между планами-графиками подпроекта тестиро- 
вания и самого проекта. Там, где это невозможно, документи- 
ровать проблемы. 


Затем Джамал пригласил Лин Цу и Эмму в свой кабинет для обсужде- 
ния распределения задач в предстоящем проекте “Суматра”. Он предста- 
вил свой план-график и рассказал о методах, которые он использовал для 
получения оценок фаз выполнения тестов. Затем он описал все задачи и 
распределение ответственности за их выполнение и спросил коллег, есть 
ли у них замечания. 

“Итак, — сказала Эмма, — я думаю, ты слишком оптимистично оцени- 
ваешь наши возможности по поиску, найму и обучению в течение трех 
недель еще одного специалиста по автоматизированному тестирова- 
нию. Ведь если. подходящий кандидат уже имеет работу, то он появля- 
ется и принимает предложение в течение одной недели после опубли- 
кования объявления, а затем делает стандартное двухнедельное 
уведомление своему нынешнему работодателю. Не думаю, что сейчас 
есть большое количество подходящих людей, которые неподалеку бол- 
таются без дела”. 

“Ты права, — согласился Джамал. — Возможно, потребуется больше 
времени, от четырех до шести недель при энергичных поисках. Мы мог- 
ли бы также рассмотреть возможность найма на временную работу по 


контракту” 


|в Соединенных Штатах, Канаде и некоторых странах Европы агентства по подбору вре- 
менного персонала и некоторые независимые компании, занимающиеся тестированием, пре- 
доставляют сотрудников на короткие контракты (60—90 дней). По завершении контракта со- 
трудник может быть переведен в штат компании. См. Ва! “Тйе Сотриѓет Сопзийаті Смійє". 
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“С учетом планов по выпуску версий продукта в следующем году, — от- 
ветила Эмма, — нам нужен в штат еще один специалист по автоматизиро- 
ванному тестированию. Поиск контрактника, вероятно, вполне прием- 
лем, только если он рассчитывает на перевод в штат в случае, если ему 
понравится работать у нас”. 

“Или ей”, — вставил Джамал. 

“Что?” — переспросила Эмма. 

“Ты сказала, если ему понравится работа. Не забывай, что двое из луч- 
ших тестировщиков в нашей группе (это ты с Лин Цу) — женщины. Веро- 
ятно, новым специалистом по автоматизированному тестированию будет 
еще одна женщина, — ответил Джамал с улыбкой. — Но если серьезно, 
я понял твою мысль”. | 

Далее и Эмма, и Лин Цу выразили беспокойство по поводу большой за- 
грузки в ходе двух первых месяцев проекта, в период разработки системы 
тестов, проведения комплексного тестирования, и даже когда кончится 
ноябрь, проведение системного тестирования будет в полном разгаре. 
“Смотри, — Лин Цу указала на график загрузки ресурсов, — я имею по две 
задачи в течение почти трех месяцев!”) 

“Да, я знаю, как это выглядит, — согласился Джамал, —а ты знаешь, как 
это работает. Ты разрабатываешь тесты, поэтому тебе нужно их тестиро- 
вать. Это препятствует выполнению всех запланированных тестов, но 
нам и не нужны проблемы, связанные с обнаружением большого числа 
ошибок в начале тестирования. Я просто хочу быть уверен в том, что мы 
разрабатываем и выполняем тесты в соответствии с порядком, в котором 
выстроены риски, по крайней мере, как нам позволяет это делать состав 
очередного инкремента”. 

Некоторое время шло обсуждение. Джамал согласился передать одно- 
го или двух младших тестировщиков из проектов по сопровождению вер- 
сий пакета ОЁНсеАгтом в перерывах работ по этим версиям для усиления 
группы проекта “Суматра”. По мнению Джамала, хотя отдел тестирова- 
ния невелик (в нем всего 14 сотрудников), он сможет привлекать людей 
на день-два для проведения тестирования, слегка урезая тестирование со- 
провождения без сужения покрытия. 


№ этапа Этап Выполнено? 


1Е Проверка декомпозиции работ и плана-графика совместно с М 
сотрудниками, которые назначены ответственными за вьшол- 
нение задач, с особым вниманием к выявлению любых пропу- 
щенных допущений и зависимостей. 


Наконец Джамал распечатал копии подготовленных документов с пла- 
ном-графиком, таблицей контроля тестов и т.д. для группы тестирования 
и для двух человек из группы Дженни, которые будут участвовать в подго- 
товке инструментов для модульного и компонентного тестирования. Раз- 
давая копии документов, он попросил каждого не только отрецензиро- 
вать его оценки, но и дать лучшую, худшую и ожидаемую оценки для задач, 
за выполнение которых они непосредственно отвечают, и для задач, 
опыт решения или понимание которых у них имеется. 
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Собрав на следующее утро запрошенную информацию, Джамал прове- 
рил свои оценки. Подавляющая часть оценок совпала с ожидаемыми 
оценками других тестировщиков. Просматривая комментарии каждого, 
он просил аргументировать лучшие и худшие оценки. Один из экспертов 
из группы Дженни удивил его плохими оценками затрат на разработку 
тестов для комплексного тестирования. 

“Знаешь, — сказал ему Джек Нильсон, — возможно, ты прав; потребует- 
ся примерно семь недель, чтобы собрать вместе и проверить все, что нуж- 
но для комплексного тестирования. И тесты для модульного и компонент- 
ного тестирования, за которые отвечаем мы, программисты, как раз 
точно впишутся в эти рамки. Я уже видел, что так бывает”. 

“Однако, — продолжал он, — я также видел, как ход процесса ком- 
плексного тестирования серьезно нарушался по множеству причин, не 
последняя из которых — это немыслимое сокращение периода ком- 
плексного тестирования на стороне группы разработки. Понимаешь, 
что я имею в виду? Обычно происходит недооценка ресурсов на кодиро- 
вание, то есть чем-то приходится жертвовать. Одна из возможных 
жертв — это комплексное тестирование. То же происходит с модульным 
и компонентным тестированием. Если это так, группе тестирования 
приходится делать много дополнительной работы, принимая во внима» 
ние, что все ошибки, которые мы не нашли, проявляются то тут, тотам в 
ходе системного тестирования. Не утверждаю, что это обязательно слу- 
чится. Я даже неговорю о том, что слышал, как кто-то предположил, что 
время, выделенное на проведение комплексного тестирования, пока 
скрыто в плане-графике под разными названиями. Я просто хочу ска- 
зать, что тебе, вероятно, потребуется план на случай возникновения 
этой ерунды”. 

Джамал согласился с доводами Джека. Он добавил соответствующее 
примечание в план тестирования, чтобы включить его позднее в качестве 
возможного риска. - 


№ этапа Этап | Выполнено? 


1.6 Рецензирование декомпозиции работ и плана-графика силами та 
всех сотрудников группы тестирования при участии зкспер- | 
тов в проблемной области как внутри, так и вне компании. 


Теперь Джамал почувствовал, что план-график выглядит неплохо. Но 
каковы будут затраты на его осуществление? Еще важнее то, как можно 
продемонстрировать ценность этих затрат? Перед тем как заняться под- 
готовкой примерного бюджета, Джамал решил выделить немного време- 
ни на изучение вопроса, как тестирование может вернуть затраты на его 
проведение. | 


№ этапа Этап Выполнено? 
1. Работая в одиночку или совместно с приданной группой тес- 


тирования, выполнить декомпозицию работ и составить при- 
мерный план-график. 
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Использование эмпирических приемов 
для грубой оценки 


В нашем примере Джамал составил декомпозицию работ на основе ре- 
зультатов анализа рисков качества. В проектах разработки менеджеры 
разработки составляют декомпозицию работ на основе требований и ар- 
хитектуры. Эти методы называют восходящими или "снизу-вверх". Оценки 
“снизу-вверх” можно проверить с помощью нисходящих правил. В компа- 
ниях с достаточной степенью формализации процессов для нисходящих 
оценок используют такие метрики, как балльная функциональная оценка 
(Ғопсбор роіпіѕ) и ожидаемое число строк кода (ргојесіей іпеѕ ої соде). 
Однако в большинєтве компаний тест-менеджеры вынуждены опираться 
на простые эмпирические правила, сравнивающие относительные разме- 
ры различных фаз проекта разработки. Кейперс Джоунз (Сарегз Јопеѕ), 
Мартин Пол (Магап Ро!), Тим Коомен (Тип Коотеп) и Джефф Рашка 
(ей КаѕһКа) опубликовали все полезные эмпирические правила. Тем не 
менее, как осторожно заметил Джоунз, эмпирические правила неизбеж- 
но являются неточными и должны применяться совместно с декомпози- 
цией работ, если требуются достаточно точные оценки затрат в проекте". 

Один из наиболее употребляемых показателей оценки затрат на тести- 
рование — это отношение числа тестировщиков к числу разработчиков. 
Кроме только что упомянутых работ, могу порекомендовать две статьи об 
использовании эТого метода, которые можно найти в Интернете. Это ве- 
ликолепная работа `Джоанны Ротман (Јоһаппа Воштап) "і Ререпаз: 
„Бес тв оп (ће Соггесг Вано ої Оеуе]орег$ го Тезегз”. В ней Ротман пред- 
выбору правильного отношения числа тестировщиков 
к числу программистов на основе анализа рисков и приводит три приме- 
ра. Она исследует области риска, относящиеся к продукту, проекту, его 
процессам и его рабочей группе. Риски продукта — это большой объем 
и повышенная сложность. К, рискам проекта и процессов относятся ко- 
роткие сроки, отсутствие приемлемого процесса разработки, тестирова- 
ния и управления проектом и потребность в высоком качестве. Рисками, 
связанными с рабочей группой, являются неопытные тестировщики, раз- 
работчики, маркетологи, менеджеры проектов и другие ключевые участ- 
ники проекта. В статье приводится описание метода анализа представ- 
ленных рисков с целью определения, нужно ли увеличивать отношение 
числа тестировщиков к числу программистов для снижения рисков каче- 


; Эмпирические правила оценки проектов разработки, включая фазу тестирования, соб- 
ранные Джоунзом, можно найти в его книге “Еѕйтайпр Ѕойшате Соя”, в главе 11. Помимо де- 
композиции работ, Джоунз рекомендует использовать инструменты автоматизированной 
оценки, продажей одного из которых занимается его компания. Однако, по моим наблюде- 
ниям, редко какие компании, разрабатывающие и сопровождающие программное обеспе- 
чение, используют эти инструменты. Таким образом, декомпозиция работ, составленная с 
помощью инструмента управления проектом, является наиболее точным неавтоматизиро- 
ванным методом, доступным типичному тестировщику и тест-менеджеру. В статье Рашки 
естьнеплохое введение на шести страницах, однако отсутствуют некоторые важные предос- 
тережения, упоминаемые в этом разделе и в работе Джоунза. Наконец, Пол и Коомен вклю- 
чили описание некоторых эмпирических правил оценки затрат в главу 7 книги “Теѕі Ргосе55 
Гтртооетеп?. 
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ства системы. Этот подход отлично уживается с методиками, представ- 
ленными в книге. Поскольку читатель уже думает о рисках качества, он 
может включить в свои размышления и эти более широкие категории. 
Помимо работы Ротман, можно прочитать глубокую статью Кетлин 
Айберли (Каїіеєп А. фейе) и Сюзан Бартлет (Ѕиѕап Вагеш) “Езатайпв 
Тезіег ќо Оеуеюрег Кайоѕ (ог №1)”. Авторы анализируют факторы, 
влияющие на точность оценок, сделанных на основе отношения числа 
тестировщиков к числу разработчиков. Айберли переслала мне по элек- 
тронной почте ключевые идеи, зафиксированные в следующих правилах: 


1. Комбинация противоречивых систем измерений и существующие 
различия в значениях отношений приводят к ошибкам в значениях 
отношений на порядок. Следовательно, сравнение отношения, ко- 
торое имеется в вашем проекте, с любым другим бесполезно. Влия- 
ние системы измерений невозможно отделить от существующих 
различий в значениях отношений. 


2. Если предлагаемое значение отношения заметно отличается от сред- 
них колебаний значения отношения в отрасли, сопоставление может 
оказаться полезным. Например, предложение о том, что весь отдел 
должен работать при отношении 1 к 30 во всех проектах, легко пари- 
ровать ссылкой на существующие в отрасли значения отношения. 


3. Значения отношения, которые были в других проектах свашимуча- 
стиєм, можно применять при выполнении следующих условий: 


А. Используется непротиворечивая система измерений. 


В. (Почти) отсутствует информация о будущей функциональности . 
системы (в противном случае оценки затрат, например, на осно- 
ве декомпозиции работ будут значительно более точными). 


С. Полученные отношения корректируются с учетом информации 
о различиях проектов. 


(р. Ошибка в 25-50% считается приемлемой. 


А 


Если необходимо сделать первоначальную оценку затрат на основе от- 
ношения числа тестировщиков к числу разработчиков, обе статьи пре- 
доставляют достаточно информации, чтобы разумно выполнить постав- 
ленную задачу . Однако нерационально ограничиваться одним подходом. 
Комбинируя эмпирические правила Джоунса, Пола, Коомена и Рашки с 
методами на основе анализа рисков, предлагаемыми Ротман, и моделью 
факторов, влияющих на отношение, разработанной Айберли и Бартлет, 
можно уточнить грубые оценки. Выполняя различные оценки с помощью 
разнообразных эмпирических правил, в том числе получая средние оцен- 
ки, можно повысить точность окончательных оценок. Различие между 
моделями позволяет получить наилучшие и наихудшие оценки. Тем не ме- 
нее следует помнить, что при необходимости получить более точные 
оценки, по всей вероятности, наилучшим вариантом является использо- 
вание декомпозиции работ. 


1 статья Ротман доступна на муу јгоап.сот, статья Айберли и Бартлет есть в “Руосеейтрз 
оў ће ЗТАВ Мезі Сопуєтепсе 2001" и на домашней страничке Айберли ууу.КіБетіе.сот. Работая 
над книгой, мне посчастливилось обсудить эту тему со всеми авторами. 
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Объем, продолжительность и зависимости работ 


Поскольку мы рассматривали технологию декомпозиции работ проекта, 
было упомянуто, что для грубых оценок или проверки оценок, получен- 
ных с помощью декомпозиции работ, сгодятся эмпирические правила. 
Пусть мы составляем декомпозицию работ. Каков типичный перечень за- 
дач на каждой из фаз проекта, и сколько времени необходимо для их вы- 
полнения? В следующих разделах для обсуждения этой темы мы рассмот- 
рим все основные фазы проекта на примере графика гант для проекта 


“Суматра”. 


Планирование 


Как показано на рис. 3.1, Джамал разбил фазу планирования подпроекта 
тестирования на четыре основные активности. Первая — знакомство 
с проектом -- была проведена в форме стартового совещания и последо- 
вавших за ним обсуждений с менеджером продукта Кейт Эрнандес и ме- 
неджером разработки Дженни Кауфман. Это заняло один день в рассмат- 
риваемом примере, поскольку Джамал уже некоторое время проработал в 
боймаге Савеїегіа, а продукт "Суматра" является инкрементным расшире- 
нием существующей системы, которую группа Джамала уже тестировала. 

Как уже обсуждалось в главе 1, ряд факторов могут сделать знакомство 
с проектом более сложным. Например, если в проект вводится новый со- 
трудник компании, если компания недавно пережила сокращение штатов 
или реструктуризацию, если система новая или уникальная, если плани- 
руется использовать новые технологии и процессы, если для проекта или 
его подпроекта тестирования необходима значительная поддержка со 
стороны лиц с разнообразной квалификацией, знакомство с проектом 
может занять несколько дней и даже недель. 

Следующая активность на фазе планирования — это анализ рисков ка- 
чества. Джамал разбил этот этап на семь задач. Определение кандидатов в 
риски качества, как упоминалось в главе 2, состоит из исследования раз- 
личных источников и выбора основных категорий рисков качества. Ак- 
тивность также включает в себя изучение метода анализа видов ошибок 
и их влияния. Это не обязательно займет целый рабочий день Джамала, 
но продолжительность задачи будет показана как один рабочий день. Сле- 
дующая задача Джамала — определение ключевых заинтересованных лиц. 
Как и знакомство с проектом, задача упрощается за счет достаточно дли- 
тельной работы Джамала в компании. Факторы, упомянутые выше, могут 
сделать определение ключевых заинтересованных лиц и получение их со- 
гласия на участие в обсуждении более долгим, чем один потраченный 
Джамалом день. 

Как отмечалось в главе 2, само совещание по анализу видов ошибок 
и их влияния может проводиться в течение целого рабочего дня за преде- 
лами компании. Если методанализа видов ошибок и их влияния применя- 
ется для анализа рисков качества небольшой или средней по размеру сис- 
темы, один: рабочий день — это разумная оценка затрат. Более сложная 
система или анализ низкоуровневых проблем архитектуры и реализации 
могут потребовать больше времени. В одном из проектов с моим участием 
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три тестировщика потратили более двух недель на проведение подробно- 
го анализа на основе детальной архитектуры для пяти-шести совместно 
работающих подсистем. Если используется неформальная методика, ана- 
лиз может быть завершен за один день при условии, что всех участников 
удалось собрать вместе. Если нужно опрашивать каждого по отдельности, 
а затем искать пересечения в перечне рисков, вероятно, потребуется про- 
вести более одного цикла черновик-отзывы-обновление- утверждение, 
как это было учтено в планеграфике Джамала. 

В случае с графиком Джамала цикл черновик-отзывы-обновление- 
утверждение состоит прежде всего из документирования результатов 
анализа в форме анализа видов ошибок и их влияния, полученных на вы- 
ездном совещании. Это может потребовать от одного часа до одного ра- 
бочего дня в зависимости от объема собранной информации. В случае 
если проводились интервью с каждым из участников по отдельности, на- 
верняка будут иметь место конфликтующие точки зрения, которые необ- 
ходимо или привести к консенсусу или, по крайней мере, зафиксировать 
документально. Джамал выделил неделю на ожидание отзывов на черно- 
вик итогового документа с анализом видов ошибок и их влияния, но не по- 
тому, что на подготовку отзывов каждый из ключевых заинтересованных 
лиц потратит пять полных рабочих дней, а потому, что он вынужден ожи- 
дать, пока занятые люди найдут примерно по часу в своих рабочих графи- 

‚ках, чтоб выполнить эту работу. По моему мнению, выделение одной не- 
дели на подготовку отзывов вполне разумно в большинстве компании. 
Может быть, в вашей компании это не так? Подумайте об этом. Быстро ли 
отвечают сотрудники компании на электронные сообщения и входящие 
запросы, сразу ли прочитывают почту или есть ключевые заинтересован- 
ные лица, которые очень заняты и обычно не отвечают, пока не получат 
неоднократные напоминания? 

Джамал отвел один день на обновление документа после получения от- 
зывов, и в этот же день он предполагает выпустить итоговую версию доку- 
мента. Снова отметим, что при использовании персонального опроса, 
анегруппового совещания, обновление документа требует больше време- 
ни и приходится готовить не одну промежуточную версию документа. 
Вот почему я отдаю предпочтение совещанию с участием заинтересован- 
ных лиц для достижения согласованного мнения по рискам качества и их 
приоритетам. Процесс опроса обычно затягивается. Поскольку процесс 
тестирования, который я выстраиваю, как правило, основан на результа- 
тах анализа, рисков, я избегаю делать какую-либо работу до тех пор, пока 
не получу надежных результатов анализа качества. 

Заметим, что Джамал решил приступить к оценке затрат и планирова- 
нию сразу по завершении выездного совещания по анализу видов ошибок 
и их влияния. Он предположил, что на совещании удастся разрешить ос- 
новные противоречия и останется сделать лишь незначительные уточне- 
ния, поэтому можно относительно спокойно начинать оценку и планиро- 
вание. Он выделил по одному дню на составление декомпозиции работ 
и подготовку бюджета. Это обоснованная оценка для опытного менедже- 
ра, выполняющего знакомые задачи совместно с небольшой группой 
опытных специалистов. Однако если вы беретесь за новые задачи, ска- 
жем, это первый ваш проект с автоматизацией тестирования, времени 
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потребуется больше. Необходимо дать сотрудникам, ответственным за 
выполнение задач, больше чем несколько часов на раздумья о том, сколь- 
ко времени потребуется на выполнение новых задач. Когда я берусь за но- 
вую задачу, я выделяю время на ее обсуждение с опытными людьми, на 
прототипирование, чтение книг и статей для того, чтобы изучить про- 
цесс. Думаю, вполне обоснованно в этих условиях можно выделить на 
оценку затрат пару недель. Кроме того, если вы впервые взялись за со- 
ставление декомпозиции работ и подготовку бюджета, вам потребуется 
дополнительное время на изучение методов (т.е. освоение используемых 
в компании программных средств управления проектом) и на консолида- 
цию идей для подготовки хорошего плана-графика. Когда я впервые гото- 
вил оценку затрат для проекта с участием трех или четырех человек про- 
должительностью примерно в один месяц, я потратил на это целый день. 
Оценка затрат теперь, после 15 лет практики, является моей второй нату- 
рой. Но эта работа определенно не может осуществляться на основе ин- 
туиции менеджера-новичка, да и растеряться от сложностей инструмен- 
тария тоже довольно легко. 

Джамал запланировал четыре дня на согласование окончательной 
оценки и на получение одобренияу руководства проекта. Он будет показы- 
вать свои оценки своему менеджеру, примет замечания, внесет изменения 
на основе полученных замечаний и затем представит итоговую версию до- 
кумента на утверждение менеджеру. Этот процесс рассматривается в сле- 
дующих двух главах, и читатель увидит, как выполняются задачи. Четыре 
дня достаточно, если вы уверены, что представляемые оценки не будут ос- 
порены. Однако в случае, если существует большой разрыв между тем, что 
согласно анализу рисков должно быть протестировано, и тем, что в рамках. 
существующих сроков и бюджета может быть протестировано, по всей ви- 
димости, потребуется некоторое время для разрешения этого противоре- 
чия. В такой ситуации я как тест-менеджер должен помочь руководству 
проекта принять взвешенные решения по поводу рисков, связанных с уре- 
занием покрытия системы тестами. В таких случаях продолжительность 
выполнения задач, связанных с переговорами и утверждением решений, 
оценивается в неделях. 

В дополнение к подготовке примерного графика и бюджета Джамал 
включил еще одну активность — планирование. Эта активность и получае- 
мый в результате план тестирования рассматриваются в главах б и 7. Джа- 
мал предполагает потратить неделю на написание плана, причем эта зада- 
ча выполняется параллельно с оценкой затрат. Джамал намеревается 
объяснить логику, которая скрыта в задачах, определенных в декомпози- 
ции работ. Как только будет готов черновик плана, он отправит его на ре- 
цензирование заинтересованным лицам на неделю. Вновь повторюсь, 
что основанием для этой оценки является стиль работы заинтересован- 
ных лиц. Один цикл рецензирование-обновление-выпуск, запланирован- 
ный Джамалом на два дня, также зависит от графика работы заинтересо- 
ванных лиц и от их мнения о документе. Если план сложный, возможно 
более длительное согласование. Если запланированы новые и незнако- 
мые задачи, им уделяется больше внимания. 

Всего Джамал выделил три с половиной недели на завершение всех за- 
дач по планированию. Некоторая часть этого времени выделяется на 
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ожидание отзывов. Джамал потратит примерно 140 человеко-часов без 
учета периодов ожиданий, поскольку к менеджерам предъявляются тре- 
бования одновременной работы над несколькими проектами. Мой опыт 
показывает, что в большинстве проектов необходимо учитывать эти при- 
сущие природе проектной работы задержки и переключения внимания 
с одного проекта на другой. В некоторых случаях, когда можно сосредото- 
читься на работе в одном проекте, а планирование является внутренним 
делом рабочей группы, я готовлю план в течение дня, а то и нескольких 
часов. Для более сложных проектов на планирование могутуйти месяцы. 


Подбор персонала 


На рис. 3.4 показан примерный план-график выделения персонала. Заме- 
тим, что одна задача, получение требований к подбору и найму, зависит 
от задачи на фазе планирования. Джамал должен получить одобрение 
бюджета и плана-графика прежде, чем можно будет ожидать разрешения 
на подбор людей. В компании, где вы работаете, вероятно, подбор персо- 
нала происходит иначе. В некоторых компаниях требуется получить 
окончательное одобрение оценок затрат. Я также работал с заказчиками, 
у которых до начала работы по поиску и найму специалистов должны 
пройти всесторонние обсуждения контрактов. Это усложняет и удлиняет 
фазу подбора персонала. 

Джамал запланировал три недели на поиск и наем специалиста по ав- 
томатизированному тестированию и пять недель на поиск младших тес- 
тировщиков. В рассматриваемом примере Эмма указала на то, что это 
слишком оптимистичные оценки, и Джамал согласился. В периоды эко- 
номического спада трехнедельный срок для найма сотрудника вполне 
реален. Это также реальное время для поиска подходящего контрактни- 
ка. В конце 90-х во время бума Интернет-технологий (40-сот боот) най- 
ти за три недели квалифицированного тестировщика со специальными 
знаниями было нереально в большинстве отраслей высоких технологий. 
Если в компании есть отдел по работе с персоналом, его сотрудники 
должны оказать помощь в ознакомлении с фазой подбора персонала 
и в более точной оценке затрат на нее в проекте. 

В небольших и вновь открывающихся компаниях обычно нет отдела 
по работе с персоналом. В этом случае можно обратиться за помощью 
в оценке задач по подбору персонала к внешним организациям. При нали- 
чии четкого описания должностных обязанностей (этой теме посвящена 
глава 8) местные компании по подбору и найму персонала могут сказать, 
сколько времени потребуется для заполнения этих вакансий. Конечно, 
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Рис. 3.4. Фаза подбора персонала подпроекта тестирования проекта 
“Суматра”) 
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эти компании ожидают, что вы заплатите им в случае успешного поиска 
кандидата для вашей компании. Не исключено, что оценку времени, необ- 
ходимого на заполнение вакансии, они делают бесплатно, но это совсем 
не означает, что вам удастся найти подходящего человека за указанное 
время. Рекрутингонлайн и међ-сайты по подбору персонала могут пре- 
доставить некоторые идеи, как оценить время, необходимое на заполне- 
ние вакансии, но эти идеи должны применяться сучетом региона, что мо- 
жет оказать серьезное влияние на оценки. Ваши коллеги-менеджеры 
также могут поделиться своим опытом по подбору персонала, но время на 
поиск программиста со знанием С++ или ХМІ. может сильно отличаться 
от времени, необходимого для заполнения вакансии тестировщика, вла- 
деющего конкретным инструментом автоматизации тестирования. Если 
успех проекта в значительной степени зависит от скорейшего заполне- 
ния определенной вакансии, премия рекрутинговой компании может 
оказаться отличным вложением средств. 

- Последние две задачи этой фазы — обучение и ввод в проект. Джамал 
совместно с отделом по работе с персоналом компании запланировал од- 
нодневное обучение для новых сотрудников. Это обычная практика в не- 
которых компаниях, где я работал, хотя я также слышал, что период обу- 
чения может длиться до трех месяцев. В других компаниях в качестве 
метода обучения применяют классический подход: бросают в воду и смот- 
рят, выплывет или нет. (Эта тема будет рассматриваться в главах 8 и 9.) 

На фазу подбора персонала Джамал выделил чуть более пяти недель. 

Как и для фазы планирования, этот периоднетрансформируется в 200 ча- 

сов загрузки для каждого из участников: Джамала, Эммы и Лин Цу. Дея- 

тельность, требующая больших временных затрат, — это интервьюирова- 

ние кандидатов, но тщательный отбор кандидатов, как это показано 

в главе 8, может сократить число интервью, в которых вам придется уча- 

‚ ствовать. Обычно моя группа тестирования тратит примерно два 

человеко-дня на проведение одного интервью и обычно встречается не 
более чем с пятью кандидатами, чтобы заполнить любую вакансию. 


Разработка тестов 


Наиболее продолжительная фаза в подпроекте тестирования проекта 
“Суматра”) — это разработка тестов. Очень часто применяются методы 
как ручной, так и автоматизированной разработки скриптов, поэтому за- 
ранее должно быть выделено достаточно времени для разработки тестов. 
На рис. 3.5 показана фаза разработки тестов. 

Как и в случае фазы подбора персонала, Джамал установил наличие 
следующей зависимости: разработка тестов не может начаться, пока он 
не получит предварительного одобрения оценок затрат, возможно, с не- 
которыми последующими изменениями. Я предпочитаю не начинать раз- 
работку тестов, пока не выясню, какие средства тестирования: тестовые 
данные, сценарии, инструменты, скрипты, конфигурации тестовой сре- 
ды,- необходимо разработать для последующего выполнения тестов. 

Зависимости между активностями разработки показывают, когда Джа- 
мал предпочитает завершить выполнение задач этих этапов. В ряде случа- 
ев его предпочтения основываются на приоритетах рисков, покрываемых 


88 


Часть [. Планирование 


57 мапілл 43 
меч 18Я8 35 


7 Зое 9622 4350 
чинив 5 5 
СИ 
мес 5 
Ребят тышо 
ГРОЛ! мава 1000 55 
Сили маам 54 7 
7 вило. А: 
НКР Зі 
ым 
СИТА 
А Е 8 ИлЯ 
8 пром Ра. вьбсарло 
Храме 52195 ри 
ороме бла | 
Б боов Тавів 
е 
ану сне ^^ 5 
дкогнйе ПУ ато Теме | 1 
С соо овен оные" | Мо 


Рис. 3.5. Фаза разработки тестов для подпроекта тестирования проекта 
“Суматра”) 


тестами, которые необходимо разработать. Например, функциональность 
управления документооборотом считается компонентом с большим рис- 
ком, чем программа установки, обычная работа и сопровождение. Таким 
образом, Лин Цу должна завершить подготовку тестовых скриптов для тес- 
тирования вручную функциональности системы управления документо- 
оборотом до начала обновления тестовых скриптов для программы уста- 
новки, обычной работы и сопровождения. 

Иногда порядок, в котором я выстраиваю разработку тестов, соответст- 
вует порядку готовности ктестированию фрагментов системы. Например, 
комплект тестов для тестирования производительности и нагрузки чуть 
более важен (в соотношении приоритетов рисков качества), чем комплект 
тестов для комплексного тестирования, но основные функции системы 
управления документооборотом появятся в системе до того, как Эмма смо- 
жет начать тестирование производительности. Интеграция компонентов 
и комплексное тестирование начнутся, как только будет готова первая 
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пара взаимодействующих компонентов в инкременте 1. Таким образом, 
Эмма будет разрабатывать средства и скрипты для комплексного тестиро- 
вания до обновления комплекта тестов для тестирования производитель- 
ности и нагрузки. 

Часть действий по разработке тестов связана с переработкой сущест- 
вующих ручных и автоматизированных тестовых скриптов. Естественно, 
что сложные и объемные тестовые скрипты потребуется обновлять доль- 
ше, нежели более короткие. Например, Джамал и Лин Цу оценивают в де- 
сять дней объем работы по переработке тестов для программы установки, 
обычной работы и сопровождения и выделяют пять дней на обновление 
тестов для обработки ошибок. Эти оценки основаны на предположениях 
Лин Цу и Джамала, что система управления документооборотом вызовет 
множество эксплуатационных накладных расходов, в частности на измене- 
ние оффлайновых носителей информации и сопровождение системы 
управления иерархическим хранилищем данных, а множество ошибок, ве- 
роятно, числом, несколько большим, чем для версии ЗреедуМкег 3.0, бу- 
дет в основном связано с такими аспектами, как недоступные или повреж- 
денные файлы. | 

Работа по обновлению автоматизированных тестов для регрессион- 
ного тестирования функциональности (представлено в графике Гантта 
как “Обновить скрипты для 5рееду\тиег 3.0”)) оценивается в пять дней, 
а на пересмотр комплекта тестов для тестирования производительно- 
сти и нагрузки отводится десять дней. Эти цифры отражают выводы 
Эммы и Джамала о том, что изменения в существующей функционально- 
сти представляют, в основном, несколько новых диалоговых окон, кото- 
рые могут появиться для взаимодействия с системой управления доку- 
ментооборотом, а также корректировку работы некоторых старых 
функций в результате исправления ошибок. Более существенные по- 
следствия изменения производительности появляются в системе управ- 
ления документооборотом, и число состояний системы может сущест- 
венно возрасти (см. главу 10). 

Для написания новых ручных и автоматизированных тестовых скрип- 
тов потребуется больше времени, чем на переработку старых. На подго- 
товку новых автоматизированных тестовых скриптов для системы доку- 
ментооборота выделено 25 дней, тогда как на обновление существующих 
тестов отводится лишь пять дней. 

Для тестовых сценариев могут потребоваться особые данные. Напри- 
мер, в проекте, где мы тестировали приложение по обработке ссуд для 
приобретения недвижимости, нам пришлось загружать специальные дан- 
ные в приложение и несколько удаленных серверов, которые предостав- 
ляли нашей системе информацию об оценке кредитоспособности. В дру- 
гом проекте сеть серверов интерактивной речевой связи (например, 
телефонная банковская система) была соединена с центром обработки 
вызовов, и в подсистеме центра обработки вызовов требовались совмест- 
но используемая база клиентов и подмножество данных об этих клиентах, 
загруженное в каждый сервер интерактивной речевой связи. Создание 
такого множества файлов с данными потребовало покупки специального 
инструмента тестирования и выделения трех человеко-месяцев на двух- 
месячный период. 


Часть І. Планирование 


В случае автоматизированного тестирования иногда можно использо- 
вать как коммерческие, так и бесплатные инструменты тестирования. 
В этом случае разработка тестов — это вопрос программирования или на- 
стройки инструмента под нужды пользователя. Эмма занимается как раз 
этим при разработке тестов для проверки производительности и нагрузки. 
Однако в некоторых случаях требуется разработать инструмент тестирова- 
ния. Эмма создала такой инструмент для разработки тестов комплексного 
тестирования. Я часто видел, как заглушки, тестовые драйверы и тестовые 
данные, используемые для успешного модульного и компонентного тести- 
рования, образуют отличные инструменты для комплексного и системно- 
го тестирования. 

План-график должен также предусматривать время для проверки са- 
мих тестов независимо от того, новые они или старые, ручные или авто- 
матизированные. До определенной степени этот период накладывается 
на период первого выполнения тестов. Однако я полагаю, что включение 
времени и затрат ресурсов на задачи по верификации тестов позволяет 
точнее оценить затраты в подпроекте. В противном случае время на по- 
иск и исправление проблем в тестах тратится в первых одном-двух циклах 
тестирования, что в конечном счете приводит к перерасходу времени на 
выполнение тестов. | 

При подготовке плана-графика разработки тестов Джамал, Лин Цу 
и Эмма опирались на свой предыдущий опыт решения подобных задач 
при оценке продолжительности и затрат ресурсов на каждую задачу. Ме- 
тоды Дельфийского Оракула, “трех точек” и широкополосный метод мо- 
гут применяться для выявления знаний группы. - 

Эмпирические правила разработки тестовых сценариев изложены в 
“Езнтайтр 5о/їшате Со55”, написанной Джоунзом (Јопеѕ). Однако я видел 
достаточно много разных вариантов разработки тестов, чтобы выбирать 
в качестве основы оценок отдельных задач тестирования данные метри- 
ки. Если посмотреть на последние четыре проекта, в которых я участво- 
вал, то в них использовались следующие измерения: 


= Интернет-приложение - 350 человеко-дней на разработку 170 тес- 
товых сценариев 


т Сеть интерактивной речевой связи и центр обработки звонков — 
1200 человеко-дней на разработку 1157 тестовых сценариев 


и Обработка ссуд на приобретение недвижимости — 20 человеко- 
дней на разработку 37 тестовых сценариев 


и Анализ данных маркетинга — 45 человеко-дней на написание 86 тес- 
товых сценариев 


х ‚ Для введения в основы оценки затрат в проектах и для знакомства с другими навыками 
по управлению проектами рекомендую обратиться к М/уѕоскі и др. “Ефесние Рея 
Матарететі". В этом полезном материале, разбавленном жизненными примерами и сквоз- 
ным рассмотрением одного конкретного случая, подробно описываются методы оценки за- 
трат. Это групповые, итеративные методы получения наилучшей/наихудшей/ ожидаемой 
оценки с помощью мозгового штурма. Также полезна статья Риты Хэдден (Виа Наддеп) 
“СгейіЫе Езитацопз бог Зла! Ргојесіѕ”, опубликованная в "5о/їшате Оцаїйу РгодезяюпаГ. В ней 
показана вариация метода, использующая экспертные оценки участников рабочей группы 
проекта. 
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В среднем требуется восемь человеко-часов на подготовку одного тес- 
тового сценария, но стандартное отклонение равно шести человеко- 
часам. Каждый из этих проектов имеет различное сочетание точности 
попадания тестового сценария, числа условий, покрываемых тестовым 
сценарием, ручного и автоматизированного тестирования, автоматиза- 
ции с использованием коммерческих инструментов и средств собствен- 
ной разработки, разработки тестовых данных и существовавших тестов 
для повторного использования, а также других факторов. Для сравнения, 
применение эмпирических правил Джоунза на 100 000 строк кода (100 
КЗГОС) программы дает около одного человеко-часа на тестовый сцена- 
рий. Затраты на разработку тестов в проекте Интернет-приложения при- 
мерно в четыре раза отличаются от затрат в проекте по анализу данных 
маркетинга. 

Оценка разработки тестов в проекте “Суматра”, сделанная Джамалом, 
дает примерно 75 человеко-дней на написание от 40 (начальная оценка) 
до 60 (включая 50% прибавки на непредвиденные обстоятельства) тесто- 
вых сценариев. Это соответствует данным для проектов по разработке 
Интернет-приложения и обработке интерактивной речевой связи. Я счи- 
таю, что вполне надежно предположить, что похожие проекты с похожи- 
ми группами тестирования, технологиями и методами покажут примерно 
одинаковые цифры затрат на тестовый сценарий, но снова мы обязаны 
рассмотреть множество различных факторов. Предположение, что “про- 
ект В такой же, как проект А, а в проекте А мы потратили два человека-дня 
на тестовый сценарий при разработке тестов, следовательно, это можно 
использовать как оценку и не рассматривать остальные факторы, влияю- 
щие на время разработки тестов”, возможно, через некоторое время не 
даст точной оценки. Еще менее точным будет применение чужих эмпири- 
ческих правил. Данные моих проектов и эмпирические правила Джоунза 
иллюстрируют, что разброс данных может отличаться на порядки, и 
оценка, которая расходится с фактом на 1000%, не слишком полезна. 

Группа тестирования Джамала будет разрабатывать тесты на протяже- 
нии большей части проекта, 26 недель. Однако основная часть этой рабо- 
ты относится к периоду в 11 недель, начиная с середины сентября и закан- 
чивая концом ноября. В течение этого времени Эмма, Лин Цу и вновь 
принятый на работу специалист по автоматизированному тестированию 
будут работать практически полный рабочий день над обновлением, на- 
писанием и верификацией тестов. 


Настройка тестовой среды 


По сравнению с продолжительной фазой разработки тестов Джамал за- 
планировал относительно короткую четырехнедельную фазу по настрой- 
ке тестовой среды (см. рис. 3.6). Сначала должны быть закуплены клиент- 
ские рабочие станции и серверы. Оценка в пять и десять дней 
соответственно указывает на четкий и простой процесс их приобретения 
в 5оймаге Саѓеегіа. Также элементами среды являются вполне обычные 
доступные в свободной продаже аппаратно-программные средства. Ника- 
кой внутренней разработки аппаратных и программных средств (за ис- 
ключением самой системы ЅреейуМгігег), специальных заказов на внеш- 
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Рис. 3.6. Фаза настройки тестовой среды 


нюю разработку средств или чего-то подобного не планируется. 
Я участвовал в нескольких проектах с применением заказного аппаратно- 
го обеспечения. В этих случаях планировались продолжительные перио- 
ды для создания заказных систем. 

Работа по установке и настройке тестовой среды выполняется глав- 
ным образом группой системных операций и администрирования под ру- 
ководством Кейта Ли. Три дня на настройку клиентских машин и десять 
дней на конфигурирование каждого сервера означают, что группа Кейта 
может быстро реагировать на запросы Джамала. Я работал в проектах, 
где это было не так, особенно в тех случаях, когда группы поддержки сете- 
вых операций были малочисленны. Иногда при установке серверов воз- 
никают вопросы безопасности, особенно если серверы должны быть 
включены в корпоративную сеть. Все эти факторы необходимо прини- 
мать в расчет. 

Сложная тестовая среда может потребовать больших затрат времени 
и ресурсов. В одном из проектов я потратил два человека-месяца на пла- 
нирование и руководство конфигурированием тестовой среды. Группа 
сетевых операций израсходовала наустановку и настройку тестового обо- 
рудования 36 человеко-месяцев!. 

Бывает, что установка и настройка тестовой среды тривиальны. В од- 
ном из проектов мне пришлось купить единственную рабочую станцию, 
заменить процессор и добавить оперативной памяти на сервере. Я израс- 
ходовал примерно один человеко-день на эту работу, включая оформле- 
ние заказа, получение, подключение к сети, установку аппаратуры и про- 
верку конфигурации. Тем не менее продолжительность фазы была около 
трех недель, поскольку мы с заказчиком должны были договориться 
о том, на какой среде проводить тестирование приложения. 


Некоторые средства и методы управления работами по конфигурированию сложных и 
больших тестовых сред рассмотрены в главах 6 и 7 книги Вех ВіасК "Матаріпе іе Тейте 
Руүосеѕѕ, 5есопа Е@тот”. 
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Выполнение тестов 


Джамал планирует провести 11 двухнедельных тестовых раундов в ходе 
системного тестирования. Из них три раунда будут проведены после до- 
бавления последнего инкремента. Джамал принимает еженедельно тес- 
товую версию (с исправлениями ошибок, обнаруженных на ранее выпол- 
ненных тестовых циклах) в течение всего системного тестирования, за 
исключением последнего двухнедельного раунда, который он планирует 
целиком посвятить тестированию “кандидата в золотую сборку”. Графи- 
ческое представление этого плана показано на рис. 3.7. 

Первое предположение состоит в том, что каждый раунд можно завер- 
шить за две недели. Ранее в нашем примере Джамал использовал таблицу 
для определения продолжительности каждого раунда. Он оценил необхо- 
димые затраты персонала и объемы доступного оборудования на каждый 
тестовый сценарий, а затем поработал с планами по персоналу и оборудо- 
ванию и пришел к выводу о двухнедельном раунде. Конечно, это только 
примерная оценка. Поскольку Джамал предполагает, что помимо уже 
имеющихся будут разработаны дополнительные тесты, то, основываясь 
на данных предыдущих проектов, он заложил в план 50% дополнитель- 
ных тестов. Также в план-график включено время на исследовательское 


ННИНИНИ! 
ПРИН Й 


ча 
Подготовка сборок 


5 Инкремент 1 


«Кандидат в золотую сборку» 


— т з Верификация исправленных дефектов 


Е __ - - Выполнение запланированных ручных 
1 иавтоматизированных тестов 


Е - - ~ Исследовательское тестирование і 


х 


Рис. 3.7. Подробный план проведения системного тестирования 


Часть І. Планирование 


тестирование, которое может увеличиваться или уменьшаться в зависи- 
мости от изменений рисков, относящихся к выполнению тестов. 

Один из других неизвестных ему заранее факторов — это сколько де- 
фектов группа тестирования будет находить в каждом цикле (что удлинит 
выполнение тестовых сценариев, обнаруживших ошибки), а также сколь- 
ко исправленных дефектов будет в каждой тестовой сборке (что можетуд- 

‘линять или укорачивать продолжительность верификации исправления 
дефектов в начале каждого тестового цикла). Я обычно использую сле- 
дующее эмпирическое правило: при получении относительно качествен- 
ных версий и при недельном цикле требуется четыре-шесть часов для ве- 
рификации дефектов. Я также допускаю, что могу добавить еще немного 
времени (примерно 20%) к планируемому периоду выполнения тестово- 
го сценария для подготовки отчетов о дефектах (см. главу 14). 

Число найденных ошибок не берется в расчет при оценке длительно- 
сти раунда, а это приводит нас к некоторому допущению. Джамал счита- 
ет, что он может провести 10 раундов тестирования, в ходе которых бу- 
дут найдены все ошибки, подлежащие обязательному устранению. 
В последнем, 11-ом, тестовом раунде для “кандидата в золотую сборку” 
он не планирует найти такие ошибки. Но можем ли мы быть уверены, 
‚что так и будет? 

Для ответа. на этот вопрос существуют статистические методы, ис- 
пользующие модели устранения дефектов. Во втором издании книги 
“Матс; апа Моагіз їп 5о/їшате ди у Епріпеетіпо" Стефан Кан (5іерпеп Кап) 
подробно описывает некоторые из этих моделей. Если требуется точная 
оценка числа тестовых раундов для обеспечения надлежащего качества 
поставляемого продукта, можно воспользоваться одной из моделей на ос- 
нове измерений. Базовая модель устранения дефектов на основе факти- 
ческих данных предыдущих проектов обсуждается в “СММ іп Ргасисе”, 
написанной Панкоджем Джелотом (Рапко| ]а1о{е), а также во втором из- 
дании моей книги “Мапаріпр іће Тезійпр Ргосезз”. Если в компании имеются 
хорошая база данных дефектов с отслеживанием изменения их статуса и 
средства для оценки общего числа дефектов в системе (см. главы 4 и 14), 
можно опереться. на базовую модель устранения дефектов Джелота. 
Уоттс Хемфри (Майя НитрЬгеу) в книге “Витодисйот іо іће Ретзопаї 5о0/їшате 
Руосе55" обсуждает модели устранения дефектов одним человеком, хотя 
они ориентированы больше на программистов. 

В большинстве случаев сроки выпуска имеют большее значение, чем 
тестирование и исправление каждой найденной в конце проекта ошибки. 
Это одно из преимуществ жизненного цикла итерационной разработки. 
В рассматриваемом примере, если инкремент 5 будет нестабильным, про- 
ектная группа может вернуться к инкременту 4 и сосредоточиться на под- 
готовке его к выпуску в объявленный срок. Джамал опирается на эту воз- 
можность, когда планирует число тестовых раундов, отсчитывая срок 
в обратном направлении от даты выпуска к дате получения первого ин- 
кремента для системного тестирования. 


| Для прогнозирования числа найденных и исправленных в проекте дефектов не требует- 
ся использовать все имеющиеся в базе данные, хотя это может потребоваться для более точ- 
ного прогноза. На меб-сайте этой книги есть шаблон Езіта‹ѓеа Вих Еіпа-Еіх.хіѕ, использую- 
щий простую модель, которая обычно дает неплохие результаты. 
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Г. оворя об инкрементах и поставке определенных фрагментов функ- 
циональности, в разделе "Разработка тестов” я утверждал, что такие со- 
ображений до некоторой степени могут быть стимулом при подготовке 
определенных видов тестов. Это также часто является фактором для 
выполнения тестов. Если в проекте, использующем каскадную модель 
системной разработки, вы отвечаете только за системное тестирова- 
ние, одним из критериев начала тестирования может быть получение 
версии с полным набором реализуемых свойств. В этом случае вся 
функциональность должна быть реализована в системе до начала тес- 
тирования. 

Однако в итерационной, спиральной (зрігаї) модели, экстремаль- 
ном программировании и других моделях, в которых новые компонен- 
ты и функции поступают в ходе всей фазы тестирования, оценки за- 
трат должны учитывать порядок. поступления на тестирование 
определенных компонентов. Это всегда верно для комплексного тести- 
рования, которое зависит от сроков готовности различных связующих 
и интерфейсных компонентов. В одном из проектов я работал с про- 
ектной группой над определением последовательности из шести 
стержневых фрагментов для комплексного тестирования, последним 
из которых была система целиком, а началом было небольшое число 
кусков каждой подсистемы, к которым добавлялись по мере готовно- 
сти другие кусочки. Добавление фрагментов происходило в порядке 
уменьшения риска вероятности или опасности проблем для жизнеспо- 
собности системной архитектуры. Помимо влияния на оценку затрат и 
сроков выполнения работ, это имело последствия для логики системы 
и покрытия ее тестами. Данные аспекты более подробно рассматрива- 
ются в главах 7 и 11. 

Джамал запланировал пять раундов интеграционного тестирования, 
все, кроме последнего, продолжительностью в четыре недели. Каждый 
раунд соответствует одному инкременту. Это аналогично описанной ме- 
тодике стержневых фрагментов. Комплексное тестирование посвящено 
поиску ошибок в связях и взаимодействии компонентов, поэтому Джамал 
считает, что он сможет найти все такие ошибки и проверить их исправле- 
ние в течение четырех недель. Поскольку это первый опыт применения 
жизненного цикла инкрементной разработки в компании Зоймаге 
Саїегегіа, последнее предположение может быть неверно. Однако с уче- 
том времени предоставления инкрементов на тестирование к 
график соответствует общему плану-графику проекта. 

Вграфике Джамала 25 недель отводится на выполнение тестов со зна- 
чительным перекрытием фаз комплексного и системного тестирования. 
Трудозатраты оцениваются в 366 человеко-дней; при этом учитываются 
четыре младших тестировщика, три тестировщика и часть рабочего вре- 
мени Джамала. 


1 Еще в 1984 г. Борис Бейзер (Вогіѕ Вейгег) в книге "бо/їшате будет Теѕйпр апа Оцайу 
Аззитатег написал хорошую главу об использовании рисков для последовательной разработ- 
ки и комплексного тестирования систем. Также подробное обсуждение комплексного тес- 
тирования можно найти в книге “Зудетайс 5о/їшате Тезіпр", написанной Риком Крейгом (Віск 
Сгаів) и Штефаном Яскилем (5гекап |азкієї). 
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Переход на доллары и центы 


Теперь читатель должен неплохо представлять, как составить декомпози- 
цию работ и оценить ресурсы и сроки выполнения работ для подпроекта 
тестирования. Эти оценки постепенно все больше и больше обрастают 
подробностями, которые определяют время с точностью до дня и позволя- 
ют сопоставить ресурсы с конкретными задачами. Хотя план в виде графи- 
ка Гантта дает общую картину в терминах времени, большинство ин- 
струментов управления проектом не могут так же хорошо справиться 
с финансовыми аспектами проекта. В следующей главе мы изучим, как на 
основе декомпозиции работ составить бюджет. Также мы изучим увязыва- 
ние бюджета с тем вопросом, о котором в действительности заботятся 
старшие менеджеры, высшее руководство и заинтересованные лица, а 
именно с возвратом инвестиций. | 


ГЛАВА 4 


Не сколько стоит, а сколько 
экономит: бюджет и возврат 
инвестиций 


екомпозиция работ и план-график помогают нам понять, сколько 

времени и ресурсов необходимо для выполнения подпроекта тести- 
рования, покрывающего все риски, выявленные ранее в ходе анализа 
рисков качества. Однако мы пока не рассматривали еще один важный ас- 
пект организации тестирования — финансовый. На этом этапе процесса 
оценки затрат мы обсудим, как на основе декомпозиции работ можно со- 
ставить бюджет, который соответствует финансовым ограничениям про- 
екта. Получив бюджет и план-график, мы будем иметь полную оценку 
затрат, которая может использоваться в качестве первоначального пред- 
ложения руководству. 

В ходе обсуждения с руководством границ тестирования в проекте 
я часто вынужден соглашаться с их урезанием. (Это означает, что тести- 
рование будет покрывать меньше рисков системы качества или покроет 
эти риски, но они будут проверяться менее детально, либо и то и другое 
вкомбинации.) Сокращение границ тестирования будет продолжаться до 
тех пор, пока группа управления проектом и тест-менеджер не перейдут 
от обсуждения того, что они должнытестировать, к обсуждению того, что 
они могутпротестировать в границах контекста проекта. Правильно про- 
веденный анализ рисков (см. главу 2) обычно помогает группе управле- 
ния проектом провести разумные сокращения в границах тестирования 
на основе представлений о рисках. 

Конечно, нам хочется бытьуверенными, что в ходе обсуждения осуще- 
ствимых графика и бюджета мы не провалим защиту адекватного тести- 
рования. Выбор правильного множества тестов для данного проекта -- не 
только техническая задача, это также политика и бизнес. Мы должны убе- 
дительно объяснить, почему мы думаем, что определенные тесты важны 
для проверки критических рисков качества, и что ресурсы, которые мы 
намерены израсходовать на тестирование каждого риска, будут использо- 
ваны правильно. К. счастью, процесс подготовки бюджета также предос- 
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тавляет тестировщикам возможность оценки отдачи от инвестиций втес- 
тирование. Существует несколько методов, удобных для этой цели. 
Вычисления возврата инвестиций, хотя и несколько грубые, способству- 
ют поддержке наиболее разумного и тщательного тестирования, которое 
может обеспечить проект. 


Анализ возврата инвестиций в тестирование 


Предыдущие шаги составления бюджета были механическими, поэтому 
мы не будем обсуждать их до тех пор, пока не покажем, как Джамал рабо- 
тает с задачами. Вместо этого рассмотрим понятие возврата инвестиций 
в тестирование. Как тестирование приносит доход компании?! 

Начнем с того, что мы стоим перед фактом, что некоторые менеджеры 
смотрят на тестирование, как на большую черную дыру в конце проекта. Им 
кажется, что чем больше они тратят на тестирование, тем больше оно требу- 
ет новых средств. Другие менеджеры считают тестирование полезной дея- 
тельностью, приносящей прибыль в ходе всего проекта. Они уверены, что 
разумные инвестиции в тестирование приносят весьма заметную отдачу. 

Как тестировщик-профессионал вы обнаружите, что лучше работает- 
ся со вторым типом менеджеров. Как мы можем убедить менеджеров, что 
тестирование — это удачное вложение средств, и с пользой обсудить воз- 
можную отдачу? Чтобы проанализировать возврат инвестиций на тести- 
рование, вновь взглянем на четыре уже упомянутых основных способа, 
посредством которых тестирование приносит отдачу: 


1. Обнаружение ошибок, которые устраняются, и даже предотвраще- 
ние их внесения. 


2. Обнаружение ошибок, которые не устраняются, но о которых ста- 
новится известно. 


Нижеследующее обсуждение включает в себя подробное изучение различных финансо- 
вых вопросов, которые могут оказаться для читателя лишними. Упрощенное представление 
тех же понятий можно найти в моей презентации “Ропг У/ауз Теѕўпр Аааѕ Уаїше" на 
ммм техЫасксопзит.сот, сопровождающейся аудиозаписью моего основного выступле- 
ния на эту тему, сделанного на ЕџгоЅТАК 2000 в Эдинбурге, Шотландия. 
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3. Проведение тестов, которые снижают (потенциально затратные) 
‚ риски. 


4. Обеспечение проекта своевременной, точной и заслуживающей 
доверия информацией. 


Рассмотрим каждый из этих способов, чтобы завершить общий анализ 
возврата вложений в тестирование. После обсуждения принципов для ка- 
ждого варианта получения прибыли от тестирования мы вновь вернемся 
к Джамалу Брауну, его бюджету для проекта Ѕреейу\гігег и возврату инве- 
стиций в его подпроект тестирования". 


Исправленные и предотвращенные ошибки 


Вычисление возврата инвестиций для найденных (при тестировании) де- 
фектов, а затем исправленных либо предотвращенных (работой группы 
тестирования) до выпуска системы приводит нас к использованию хоро- 
шо известного подхода под названием “анализ стоимости качества”. Ме- 
тод стоимости качества, точнее, стоимости плохого качества, разбивает 
затраты, связанные с качеством на две категории, каждая из которых в 
свою очередь также делится на две части: 


1. Затраты на соответствие (сопіогіпапсе), включающие в себя все за- 
траты, связанные с обеспечением или проверкой качества системы; 


= Затраты на предотвращение несоответствий (СС, едотеращенця)» 
включающие в себя затраты на обучение, экспертные оценки до- 
кументации и другие реальные методы контроля качества. 


и Затраты на обнаружение несоответствий (ССируж,ния), Которые 
включают в себя траты, связанные с подготовкой к тестирова- 
нию, выполнением каждого теста (один раз) и обсуждением об- 
наруженных несоответствий. 


2. Затраты на несоответствия, включающие в себя все затраты, свя- 
занные с проблемами качества системы, т.е. затраты, относящиеся 
к невозможности достигнуть совершенного качества с первой по- 
пытки: 


и Затраты на внутренние несоответствия (КС, утренчио)» ВКЛЮЧАЮ- 
щие в себя затраты на подготовку отчетов о дефектах, исправ- 
ление дефектов, подготовку исправленной версии, проверку и 
подтверждение, что ошибки исправлены, регрессионное тес- 
тирование, переработку тестов и документации, реагирование 


1 рик Крейг (Віск Сгаір), соавтор “5уяетайс Зойшате Тезійпр" и мой коллега, консультант по 


тестированию, указал, что тестовые сценарии становятся полезной частью документации 
системы. В дискуссии по электроиной почте по поводу этой главы он писал: “Другой неожи- 
данный доход от инвестиций в тестирование состоит втом, что сами тестовые сценарии мо- 
гут рассматриваться как часть системной документации, особенно для древних систем, спе- 
цификации требований и архитектуры которых давно устарели. Часто ли к тебе приходят 
программисты с вопросом: “Рекс, можно взглянуть на твои тестовые сценарии, чтобы по- 
нять, как эта система должна работать?” На самом деле, это отличный признак того, что ты 
мах лестукуканнку сустхон. 
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на изменения в системе, задержки выпуска или поставки систе- 
мы ит.п. 


ш Затраты на внешние несоответствия (ЁРС„„инш), которые обычно 
включают в себя большинство внутренних затрат на устранение 
несоответствий плюс дополнительные потребности в техниче- 
ской поддержке, поставке версий и патчей сопровождения, по- 
тенциальный ущерб репутации компании и снижение продаж, 
общение с рассерженными клиентами и другие еще более немате- 
риальные потери. 


Можно представить стоимость качества в виде формулы: 


С качества = (СС, предотвращения й ССобнаружения) + (РС, внутренние + Е Смешни) 


Вы можете спросить: “Ну и что? Как эти хитрые трюки с расщеплени- 
ем и соединением финансовых данных могут мне помочь?” Хороший во- 
прос. Это поможет вам, недофинансированному профессионалу, по- 
скольку люди, которые изучили эту тему, обнаружили, что для многих 
компаний независимо от отраслей, в которых они работают, затраты на 
внешние несоответствия обычно существенно превосходят затраты на 
предотвращение, обнаружение и внутренние несоответствия. Филипп 
Кросби (РШір Сгозіу) в книге " Оцаїйу Б Егег” объясняет, что инвестиции 
в качество могут принести ощутимый положительный эффект, если изме- 
рить его в терминах обнаруженных и устраненных проблем до того, как 
их увидели заказчики . 

Точные затраты, связанные с внутренними и внешними несоответст- 
виями, могут значительно различаться для разных проектов разработки 
и сопровождения систем. Данные по отрасли нелегко обнаружить в Ин- 
тернете или в других открытых источниках. Старое эмпирическое прави- 
ло, позаимствованное из "5о/їшате Епріпеетіпр Есопотіс» Барри Бёма (Ваггу 
Воеһт), гласит, что затраты на исправление ошибки на фазе требований 
и архитектуры равны $1, затраты на исправление при обнаружении ее 
программистом равны $10, при обнаружении независимой группой тес- 
тирования и при исправлении до выпуска программы равны $100, при об- 
наружении заказчиком и последующем исправлении программистом, 
внутреннем тестировании и выпуске в рамках версии сопровождения 
равны $1000.'Данные оценки могут в зависимости от области, в которой 
работает читатель, рассматриваться как чересчур консервативные или 
слишком либеральные (см. врезку “Калькуляция стоимости дефекта”))*, 

Это средние затраты на ошибку: некоторые ошибки стоят дороже, не- 
которые дешевле в зависимости от сложности их исправления, объема 
необходимого регрессионного тестирования, влияния исправления на 


1 Введение в эту тему есть в предисловии книги Кросби. (Роб Сабурин (ВоЪ Забоигіп), 


один из рецензентов, отметил, что необходимо убедиться в правильном понимании заго- 
ловка — некоторые считают, что добиться качества ничего не стоит.) Более подробно см. 
Лігап, Ступа, “Оцайёу Сопітої Напабоок" или Сатарапе[а, “Рип! оў Оцаїйу Соя’. Наконец, 
о применении этого понятия в производстве программных продуктов см. Заир щег еќ аї., 
“Еуаванпе Фе Собі ої Ѕоћмаге ОпаШу” в " Соттитісаййоп5 оў іће АСМ”, Уоїате 41, МатЪег 8 
(Аџр 1998). 
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БЕ 


другие части системы и т.д. На любом отдельно взятом уровне качества 
различие в затратах на конкретную ошибку не играет роли. Как я покажу 
ниже, окупаемость тестирования предполагает, что группа тестирова- 
ния обнаружит ошибки, исправление которых обошлось бы более чем 
в $1000, если бы это было на стадии эксплуатации системы. Вообще гово- 
ря, чтобы получить положительное сальдо от инвестиций на тестирова- 


ние, суммарная стоимость затрат на обнаружение дефектов и затрат на . 


внутренние несоответствия должна быть меньше, чем суммарные затра- 
ты на внешние несоответствия, независимо от того, проводилось ли тес- 
тирование и были ли найдены ошибки. Если группа тестирования растра- 
чивает попусту время и ресурсы в поисках ошибок, которые не относятся 
к реальному использованию системы и критическим рискам ее качества, 
то окупаемость тестирования будет невелика независимо от числа обна- 
руженных ошибок. 

Усредненные затраты на ошибку, подлежащую обязательному исправ- 
лению, вероятно, не являются константой для различных уровней каче- 
ства системы. Эта закономерность имеет ряд интересных следствий, ко- 
торые не будет излишним упомянуть ниже. 

Скажем, вы потратили 1 миллион долларов на проект разработки. 
Пусть степень удовлетворенности заказчика можно измерить в процен- 
тах от 0 до 100. При удовлетворенности заказчиков в 0% все ваши заказчи- 
ки, воспользовавшись 30-дневной гарантией, возвращают отвратитель- 
ную систему, т.е. вы не получаете никакого дохода от проекта. Если все 
вернут систему, затраты на несоответствия составят, как минимум, 1 мил- 
лион долларов, поскольку весь проект.оказался простой тратой денег из- 
за низкого качества. При 100%-ной удовлетворенности заказчиков, 
т.е. если все полностью удовлетворены'и никто не вернул продукт, затра- 
ты на несоответствия будут равны затратам, связанным с внутренними 
несоответствиями, т.е. с исправлениями ошибок до выпуска версии. 

Теперь допустим, что группа разработки внесла 1000 дефектов в систе- 
му в ходе разработки. Предположим, что для дефектов, обнаруженных 
внутри проекта, треть исправлена на фазах требований и архитектуры, 
треть исправлена программистами в ходе кодирования, отладки, модуль- 
ного и компонентного тестирования, атреть- в ходе комплексного и сис- 
темного тестирования, проводимого тестировщиками. Таким образом, 
по эмпирическому правилу Бема, система, в которой исправлены все 
ошибки до выпуска версии, имеет следующую стоимость несоответствия: 


ЛшиЖлЊ у) + ЕЗ ЛшиЖлњЊ і, + и ЛшиЖлЊ е) 


ЛшиЖЊа ) ЛшиЖЊа 


= $37 000 


? Марк Фьюстер (Магк Кемізіег) и Дороти Грэм (Богогу Стаһат) приводят чуть более вы- 
сокие цифры в "5о/їшате Тез Ашотайот”. Джоанна Ротман (Јоһаппа Коёћтап) на своем сайте 
эми тофтап.сот сообщает об ошибках периода эксплуатации системы средней стоимо- 
стью в $10 000. Боб Барлет (ВоЬ Вайей) из 51М Сгопр пишет, что один изего клиентов, круп- 
ный банк, оценивает средние затраты на проблемы с программным обеспечением в произ- 
водственных системах в 150 000 евро (см. "Ромег Теѕіпр” в "Росегййпрз оў йе ЕЙ Риетайопаї 
Оцаїйу Уве Еиторе" сопіегепсе, р.191). 


ЛшиЖЊа 
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на разрешение. ироаи должны: отъ учтены, 
‘вводит активность “кодирование” в систему учета: т 


жено з и поставку программного продукта. В и тес гих ао пе 
учета требуют, чтобы эти затраты калькулировались отдельно; ‚в других 


по исправлению ‘дефектов. Кроме того; не забывайте ‘посчитать ‘затраты 
‚на Сетэвую систему ть пользователей. ыы этих затрат, де- 


: сколько: падает производительность трудав день из-за зависаний персо- З 
г нальных и И Вспоминаю А. с: 


В терминах затрат на соответствие, предположим, что чем больше 
в системе дефектов, тем легче их обнаружить. Если требуется меньше за- 
трат на обнаружение дефекта, стоимость обнаружения ниже. Напротив, 
чем меньше ошибок в системе, тем труднее их обнаружить. Если нужно 
больше затратить на поиск ошибки, затраты на обнаружение выше. 

Если вы когда-либо тестировали систему, полную ошибок, то вам из- 
вестно, что квалифицированный тестировщик может найти в такой сис- 
теме ошибку. Для этого не нужны ни планирование, ни инструменты, ни 
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проектирование тестов, ни их разработка. Предположим, что в системе, 
которая может привести к 0% удовлетворенности пользователей, мы мо- 
жем обнаружить первую ошибку не более чем за $20. 

Продолжая тестирование, обнаруживая ошибки и получая новые тес- 
товые сборки, в которых эти ошибки исправлены, вы вынуждены рабо- 
тать все более напряженно, чтобы обнаружить следующую ошибку. Пусть 
система без ошибок будет давать 100%-ную удовлетворенность заказчи- 
ков, однако затраты на обнаружение последней ошибки будут стремиться 
к бесконечности. 

В этой модели тестирование и контроль качества, в конечном счёте, 
достигнут точки убывания возврата инвестиций, когда стоимость качест- 
ва достигнет минимума, как только стоимость соответствия сравняется 
со стоимостью несоответствия. 

Предположим, что каким-либо способом мы могли предсказать удов- 
летворенность заказчика на основе числа дефектов, остающихся в про- 
дукте. На рис. 4.1 представлен`график того, как могут выглядеть затраты 
на различных уровнях удовлетворенности заказчика. 

Уровень качества, минимизирующий стоимость качества, соответству- 
ет 75%-ной удовлетворенности заказчика. В терминах дефектов, постав- 
ленных заказчику вместе с продуктом, можно сказать, что это соответству- 
ет почти 100%, поскольку 90% дефектов, подлежащих обязательному 
исправлению, были устранены. Затраты на соответствие (и на контроль 
качества, и на тестирование), необходимые для достижения этого уровня 
удовлетворенности, приблизительно равны $125 000". 

К счастью, нет необходимости размышлять над тщательно разрабо- 
танной математической моделью и причудливыми графиками, подобны- 
ми рис. 4.1, чтобы применять понятие стоимости качества. Я собираюсь 
продемонстрировать способы применения этого понятия для исследова- 
ния текущего возврата затрат на тестирование и в некоторых случаях для 
оправдания увеличение затрат. Далее в этой главе в рамках проекта “Су- 
матра” будет рассмотрен пример такой ситуации. Джамал будет использо- 
вать только метод Уэллера для оценки затрат внутренних и внешних несо- 
ответствий, оценки числа дефектов в продукте и оценки числа дефектов, 
которые будут найдены. 

Наконец, раннее вовлечение в проект группы тестирования также 
способствует предотвращению ошибок. Группа тестирования, которая 
допускается до рецензирования спецификации требований или архитек- 
туры до начала разработки, сопровождения или установки, может обна- 
ружить неоднозначности, противоречия, пропущенные детали и другие 


1 Идея, что в некоторой точке затраты на соответствие превысят затраты на несоответст- 
вие, — это стандартная модель стоимости качества, развитая Джураном (Јигап) и Гриной 
(Ступа) в "Оцайу Сотіто! Напабооі, Еоитћ Едйіоп". Однако наиболее современная мысль в 
управлении качеством состоит в том, что затраты на соответствие никогда не превысят за- 
траты на несоответствие. 


? На графике видно, что общая стоимость качества в точке минимума примерно равна 
$250 000, или 25% бюджета проекта. Это может показаться нереально низким. Однако в 
"Риїпсірієз оў Оцайу Созіз") Кампанелла (СатрапеПа) и др. отмечают, что компания Каушеоп 
Еесітопіс Зузієпаз в ходе работы по подготовке к сертификации на 4-й уровень СММ 
(Сарабійу Мапийу Моде!) сократила затраты на качество с 80% почти до 20%. 


Затраты (в $1000) 


1ИИОНОХЕ ОУЯШОХО Р '1и019 оао ән ‘р еаеи ] 
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Рис. 41. Гипотетический график стоимости качества 
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проблемы в этих документах. Такого рода проблемы в противном случае 
превращаются хотя бы в одну ошибку, но обычно их больше. Тестиров- 
щики, как показывает мой опыт, особенно полезны как рецензенты, по- 
скольку они постоянно задаются вопросом: “А что, если?” и способны 
предвидеть необычные ситуации. 

Финансовая выгода от раннего вовлечения группы тестирования 
в проект — это стандартные преимущества, которые приобретаются в ре- 
зультате рецензирования документов с описанием требований и архитек- 
туры. Их трудно измерить количественно, поскольку для этого требуется 
отслеживать обнаруженные проблемы и их исправление в документации. 
Компании, использующие формальные инспекции или точные модели 
удаления дефектов, располагают процессами для отслеживания такого 
рода проблем, но в большинстве компаний таких процессов нет. Незави- 
симо от возможности количественного измерения преимуществ рецензи- 
рования силами тестировщиков, надо честно сказать, что с учетом значи- 
тельно меньшей стоимости исправления дефектов в документации по 
сравнению с исправлением ошибок в коде возврат затрат на час работы 
тестировщика по рецензированию требований и архитектуры обычно 
равен или превосходит возврат на час работы тестировщика на любой бо- 
лее поздней стадии проекта . 


Неисправленные, но известные ошибки 


Даже если обнаруженные ошибки не исправлены, процесс по-прежнему 
имеет ценность. Каким образом? Позвольте применить следующую ана- 
логию. Предположим, вы собираетесь совершить длительное летнее пу- 
тешествие на автомобиле. До начала путешествия вы, вероятно, отпра- 
витесь в ближайший автосервис проверить машину. Механик говорит, 
что под капотом все выглядит отлично, но про шины известно, что в ус- 
ловиях сильной жары, высокой скорости и низкого давления в них они 
могут отказать. Вы не можете позволить себе поменять шины, однако де- 
лаете пометку, что необходимо управлять транспортным средством та- 
ким образом, чтобы это не повлекло неприятностей с шинами, и при- 
нять необходимые предупредительные меры, например проверить 
наличие запасных частей, запаса питьевой воды, пищи, аптечки первой 
помощи и т.д. То же самое всякий раз происходит и с программными 
системами. Многие из ошибок, которые мы находим, не исправляются, 
а становятся известными ограничениями и предупреждениями пользо- 
вателям. 

В некоторых случаях мы можем принимать активные меры по недопу- 
щению пользователя в опасную зону системы, а не устранять эту зону. На- 
пример, рассмотрим дыру в программе 5реедуУУтіег: редактор не может 
работать с определенными версиями ]ауа в браузере. Программы уста- 
новки позволяют делать выбор обновления до новой версии с разреше- 
ния пользователя и предотвращают возникновение этой ситуации. 


їв “Зуяетайс 5о/їшате Тейт” авторы Крэйг (Сгаів) и Яскиль (]азКе!} поясняют идею пре- 


вентивного тестирования и методов его достижения. Модели удаления дефектов описаны в 
“Метс; апа Модеб т 5о/їшате Оиаїйу Епріпеетіпр, Зесопа Её ют” Кана (Кап). 
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В других случаях мы и наши заказчики обречены жить с ошибками. 
В этой ситуации технические писатели могут документировать извест- 
ные проблемы в описаниях отличий новой версии, руководствах пользо- 
вателя, экранах помощи, сообщениях об ошибках и другой системной до- 
кументации. Сотрудники отделов маркетинга и продаж могут передавать 
этуинформацию пользователям до приобретения или поставки системы. 
А группа технической поддержки может загрузить открытую информа- 

‚ цию о дефекте в базу знаний поддержки. Эта информация особенно по- 
лезна, если отчет об ошибке включает в себя описание обходных путей. 
Я работал в проекте, в котором два младших тестировщика потратили две 

` недели, остававшиеся до выпуска версии, на работу с менеджером техни- 

‚ ческой поддержки, инженером по сопровождению базы знаний техниче- 
ской поддержки и несколькими ведущими специалистами службы техни- 
ческой поддержки для того, чтобы убедиться, что последние понимают 
систему так же, как и тестировщики. 

Насколько полезны все эти знания о том, как система может дать 
сбой? Довольно трудно получить точные цифры. Степень, в которой об- 
ходные пути и документированные предупреждения микшируют про- 
блемы, в любом случае трудно измерить цифрами, поскольку заказчик, 
который решаетсвои собственные проблемы, применяя файлы помощи 
или руководство пользователя, не звонит в техническую поддержку, 
чтобы сообщить, что он решил не беспокоить техническую поддержку, 
поскольку имеет отменную документацию. Тем не менее скажем, что 
можно оценить время при наличии обходного пути для проблемы, если 
заказчик все же обращается в службу поддержки. Если система уже про- 
дается на рынке какое-то время, мы можем установить частоту звонков в 
техническую поддержку по поводу ошибки. (Если это новая система, мы 
можем на основе анализа рисков качества оценить частоту звонков по 
определенной ошибке на основе вероятности.) Таким образом, имея не- 
которые оценки того, сколько обнаруженных дефектов не будут исправ- 
лены, мы можем оценить экономию (в человеко-часах) времени работы 
сотрудника центра обработки вызовов технической поддержки. 


Тесты, снижающие риски 


К настоящему моменту мы определили выгоду только от найденных оши- 
бок. Мы обнаруживаем множество ошибок и снижаем ущерб посредством 
некоторой комбинации ремонтных работ, предотвращения появления 
новых ошибок, обходных путей и предупреждений. Это — управление 
рисками качества в то смысле, что риски качества после выпуска версии 
уменьшаются. Мы обнаружили определенные условия, при которых каче- 
ству системы создает угрозу определенная, известная опасность. Нам из- 
вестен вид ошибки, который оказывает влияние на определенный про- 
цент пользователей и заказчиков системы в течение определенного 
времени. Вероятно, мы не знаем эти проценты с большой точностью, од- 
нако мы можем оценить средние значения. Это позволяет измерить отда- 
чу инвестиций, как указывалось выше. 

Но верно ли, что отдачу приносит только то тестирование, которое 
ведет к обнаружению ошибок? Или, другими словами, тест, который вы- 
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полняется без ошибок, тратит впустую деньги компании? Во многих слу- 
чаях основной целью компании является не столько обнаружение оши- 
бок, сколько уменьшение беспокойства. Это означает, что отдача от 
тестирования вытекает не столько из знания того, сколько ошибок мы на- 
шли, сколько из знания того, что работает, а что — нет. 

Чтобы количественно измерить эту отдачу, можно воспользоваться 
экономической категорией замещения (за 5$ Илйоп). Замещение — это ис- 
пользование альтернативного продукта или услуги, приносящей анало- 
гичную пользу. В случае с уменьшением беспокойства обычным решени- 
ем может стать страхование. (Страхование — это просто статистически 
обоснованный механизм распространения риска на большое число дер- 
жателей полисов, т.е., с точки зрения теории, нет оснований полагать, 
что таким образом распределенный риск не может быть множеством рис- 
ков качества в проектах по созданию программных систем.) Во сколько 
обойдется менеджеру продукта “Суматра” Кейт застраховать проект от за- 
трат на несоответствие? 

Предположим, что при выполнении предыдущего проекта, до того 
как компания Ѕобуаге Саїегегіа прозорливо наняла на должность тест- 
менеджера Джамала, Кейт посетила ближайшего страхового агента. Она 
сказала: “Знаешь, Джимми, у меня есть проект системной разработки 
стоимостью в 1 миллион долларов, и я не знаю, каков уровень качества. 
Совсем. Он может быть как равным 0% удовлетворенности пользовате- 
лей (все возвращают товар), так и равным 100% удовлетворенности поль- 
зователей (все восторгаются товаром). У меня нет группы тестирования, 
программисты просто тестируют свой код, т.е. никто не обладает инфор- 
мацией, которая мне нужна. Я бы хотела купить у тебя страховой полис, 
который покрыл бы все мои затраты на несоответствия”. 

Джимми ответил: “Конечно, Кейт, у меня есть стандартный полис 
страхования затрат на несоответствия. Подпиши там, где пунктирная ли- 
ния. Это будет стоить $427 000, включая 10% моих комиссионных сверх 
25%-ной надбавки страховой компании ХУ7”. Как страховая компания 
ХУ? узнала, во сколько необходимо оценить стоимость полиса? 

Если мы отбросим наценку (прибыль и накладные расходы) и комисси- 
онные, реальная стоимость страхового полиса окажется равной $811 000. 
Эта цифра рассматривается как ожидаемая выплата, которую страховая 
компания предполагает заплатить по полисам, аналогичным данному, 
проданным большому числу полисодержателей. Страховая компания 
ХУ? могла бы получить это число, если бы располагала статистической 
моделью, которая лежит в основе кривой затрат на несоответствия, пока- 
занной на рис. 4.1, поскольку ожидаемая выплата — это сумма, с учетом 
всех возможных исходов, произведений вероятности исхода и стоимости 
исхода. Если предположить, что в отсутствии другой информации о каче- 
стве каждый из 11 исходов от 0% до 100% удовлетворенности пользовате- 


1 Замещение предполагает одинаковую пользу, а не идентичную замену. Тестирование мо- 
жет дать информацию том, какие части системы работают, а какие нет, о каких рисках стоит 
беспокоиться, а о каких не стоит. Однако тестирование не возместит затрат компании на не- 
соответствие в результате обнаружения ошибок в период эксплуатации, что под силу стра- 
ховому полису. 
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лей одинаково вероятен, то мы вычислим ааа выплаты следую- 
щим образом: 


1000 , 553, 437, 355 , 290 236, 188 145 106 70, 37 = $1000 $311 000 
11 11 11 11 11 п 11 11 пи 1 


Где можно получить модель затрат и вероятностей различных уров- 
ней качества? Купит ли на самом деле кто-нибудь такой а полис, 
если предложить его по честной цене? 

Страховые компании размышляют о моделях ожидаемых выплат на 
основе уровней риска. Для страхования жизни, например, риск связан с 
определенными результатами медицинских обследований, позволяющи- 
ми установить состояние здоровья, определить типы поведения, увели- 
чивающие вероятность травм, и возраст. Для страхования автомобиля 
риск определяется на основе стоимости вашей машины, вашей истории 
вождения и в некоторых случаях с учетом вашего криминального про- 
шлого. 

При разработке системы можно оценить вероятность и затраты опре- 
деленных исходов, начиная с полного провала проекта и заканчивая удов- 
летворенностью всех пользователей в отрасли, в которой используется 
система, учитывая выбранную технологию разработки, уровень зрелости 
процессов в компании и навыки и умения проектной группы, в частности 
группы тестирования. - 

К сожалению, подробных данных в рассматриваемых областях имеет- 
ся немного, что объясняет причины того, что страховые полисы для про- 
блем в проектах по созданию систем, ориентированных на повышенные 
запросы к качеству, не являются общедоступным товаром. Любая модель 
является ограниченной, а при отсутствии данных — очень грубой. Одна- 
ко, по крайней мере, мы сможем сделать довольно точный анализ в край- 
них точках. Мы знаем стоимость полного провала — весь проектный бюд- 
жет или в некоторых случаях стоимость всей компании. При условии, что 
мы можем надежно оценить число дефектов в продукте и средние затра- 
ты на исправление дефекта до выпуска версии, мы можем обоснованно 
оценить затраты на несоответствия при 100%-ной удовлетворенности 
пользователя. 

Таким образом, если мы можем определиться с моделью даже при на- 
личии исключительно линейной интерполяции от гибели проекта из-за 
цунами ошибок до полной удовлетворенности пользователя при нулевом 
количестве дефектов, и группа управления проектом примет эту модель 
как достаточно точную, значитли это, что они заплатят за страховку наее 
основе? Некоторые компании, вероятно, ответили бы утвердительно. 
Некоторые компании действительно купили — за очень высокую плату — 
страховку против компьютерных сбоев из-за проблемы 2000 г. Хотя все 
закончилось относительно благополучно, многие из тех, кто приобрел 
страховые полисы, возможно, до сих пор считают это разумным решени- 
ем. Если бы ситуация складывалась по-другому, а о полисах бы не позабо- 
тились, неспособность групи менеджеров управлять определенными 
классами рисков могла бы привести их в суд, а то и втюрьму. 


110 


Часть [. Планирование 


В других организациях, особенно в небольших высокотехнологичных 
компаниях, в которых разработка систем является основным бизнесом, од- 
ним из способов получения прибыли является выполнение проектов с вы- 
сокой степенью риска. Те, кто играл на бирже акций высокотехнологич- 
ных компаний в 90-е гг. прошлого века, знают, что большие риски могли 
привести к большим прибылям. (Так же, как и те, кто держал такие акции в 
2000 -- 2002 гг., знают, что те же решения могли вести к большим потерям.) 
Некоторые люди решают не приобретать полис страхования жизни, дру- 
гие считают это разумной инвестицией. Компании ведут себя так же. 
Сколько они заплатят за управление рисками качества, зависит в большой 
степени от того, насколько они болезненно относятся к рискам. 


Ведение проекта 


Если тщательно проанализировать фразу “управление рисками качества” 
(ачайу гі5к папаретеп(), можно обнаружить, что это также означает спо- 
собность принятия обоснованного решения. Словарь Мегат-Уеяет‘ 
"Сойеріаїе Дісійопату" определяет слово “тапаріпр” (управление) как "кон- 
троль или руководство с определенным навыком”, а “навык”) — как "спо- 
собность легко и эффективно использовать чьи-либо знания”. Други 
словами, для того чтобы действительно управлять рисками качества, нуж- 
но не только держать под контролем известные источники опасности, но 
и добывать информацию об общем качестве системы, и получать некото- 
рое представление о том, что это может значить для системы в будущем. 

Снова обратимся к рис. 4.1, уделив особое внимание кривой затрат на 
несоответствия. Итак, эта кривая является некоторой аппроксимацией, 
которая не подлежит непосредственному использованию ни в какой ком- 
пании, но общая форма - убывание с повышением качества — применима. 
повсеместно. 

Большинство менеджеров проектов, с которыми мне довелось рабо- 
тать, понимали, что качество системы влияет на общую стоимость разра- 
ботки, сопровождения или поставки системы в течение всего ее жизненно- 
го цикла. Поскольку часть менеджмента всегда занимается управлением 
затрат, эти менеджеры стремятся проникнуть в суть качества. Без точных, 
заслуживающих доверия и своевременно полученных результатов тести- 
рования менеджеры проектов знают очень немного об уровне качества 
своих систем. Более того, они еще меньше понимают, как эволюционирует 
качество их систем, по мере того как проект приближается к важной кон- 
трольной точке, например первоначальной сборке или версии сопровож- 
дения. 

Тестирование может позволить заглянуть внутрь качества. Чтобы это 
сделать, мы должны сначала понять общую картину рисков качества, по- 
строить окружение для тестирования этих рисков, выполнить тесты, что- 
бы оценить качество, а затем довести полученную в ходе тестирования 
информацию эффективно, точно, надежно и своевременно. Таким обра- 
зом, менеджеры проектов могут узнать, что не работает, что работает, 
а что остается за рамками исследований тестировщиков. Хорошо органи- 
зованный проект тестирования может также собрать информацию о тен- 
денциях, позволяющую сделать осмысленные предсказания уровней ка- 
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качества при том же уровне представления о них, какой финансовые от- 
делы имеют о рисках бюджета, отделы маркетинга — о рисках свойств 
системы, подразделения менеджеров проектов — о рисках сроков. Хотя 
есть еще непочатый край работы с моделями, которые позволили бы 
численно оценить точность оценки качества, имеет смысл включить не- 
которые оценки этой величины как часть анализа возврата вложений в 
тестирование. 


Заключительное замечание об оценках возврата вложений 


Цель проведения анализа возврата вложений состоит в показе бизнес- 
плана тестирования. В некоторых случаях, вероятно, есть смысл пред- 
ставить бизнес-план для проведения тестирования другими способа- 
ми. Например, Фьюстер (Кеумзіег) и Грэм (Сгаһат) показывают по- 
строение бизнес-плана для автоматизации тестирования в "50/їшате Тезі 
Ашотанот”. 

Бизнес-план для автоматизации тестирования выявляет следующий 
полезный факт. Некоторые затраты могут быть разнесены по несколь- 
ким проектам. Это правило применимо не только к скриптам для авто- 
матизированного тестирования, но и ко всей системе тестов, включая 
тестовую среду, затраты на ее конфигурирование, тестовые данные, 
многократно используемые тестовые сценарии для ручного тестирова- 
ния, некоторые другие объекты. Нужно быть реалистами, но тем не ме- 
нее иметь в виду это обстоятельство при оценке возврата инвестиций 
в тестирование. 

Что касается данного замечания, важно иметь сдержанные оценки воз- 
врата вложений. Если вы переоценили свой случай и привели производя- 
щие впечатление цифры, и какой-либо менеджер вас поймал на этом, вы 
нанесли тем самым реальный ущерб доверию вам со стороны руководства. 
Следует опираться на источники, а не брать цифры с потолка. Лучший ис- 
точник данных — ваш опыт и ранее выполненные проекты, поскольку эти 
данные наилучшим образом проанализированы и осознаны. В противном 
случае можно опираться на данные в доступных публикациях (например, 
в “Езйтайте 5о/їшате Со 5”)) или на информацию от коллег. Однако, приме- 
няя данные, полученные от других людей, необходимо потратить время, 
чтобы понять контекст, из которого взяты эти данные, и как различие меж- 
ду этим контекстом и вашим окружением тестирования влияет на приме- 
нимость данных для ваших целей. Наконец, оцените с точки зрения здра- 
вого смысла полученные оценки возврата вложений и будьте готовы 


Амо ртизация (Атогіте) | 


Распределениє затрати приво от инвестиций на серии временных. пе- 
гриодов (например, ежемесячно) либо на совокупность проектов. Показы: 
ваєт ‘средние. затраты и ты оо от ринвестиций ? перио, реме- 
ни или на проект. | | 2. 
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чества в будущем, а также определить примерное время. готовности 
системы к выпуску . 

Поскольку мы можем обсуждать проблемы не только в терминах оши- 
бок и тестовых сценариев, но и в терминах “опыта качества” пользовате- 
ля, эта оценка позволяет понять менеджменту, каков уровень качества 
системы. Как можно количественно измерить, насколько значимо это по- 
нимание для менеджмента? Попробуем это сделать, рассмотрев следую- 
щие варианты. 

Начнем с замечания, что наличие точных, своевременных, заслужи- 
вающих доверия и исчерпывающих оценок и прогнозов о качестве систе- 
мы является фундаментальной частью отслеживания хода проекта. В кни- 
ге "Езійтайпр Зойшате Соб” Кейперс Джоунз (Сарегѕ Јопеѕ) выделяет 
четыре основные корневые причины неудач проектов, одна из кото- 
рых — небрежное отслеживание состояния проекта“. 

Джоунз сообщает, что выбор более надежных способов отслеживания 
хода проекта может снизить риск неудачи проекта примерно на 50%. (Он 
определяет неудачу проекта как нарушение сроков или бюджета не менее 
чем на 25% от плановых либо как полную остановку проекта.) Джоунз так- 
жеговорит о том, что риск неудачи проекта в целом есть функция от вели- 
чины проекта, изменяющаяся от 2% для очень маленьких проектов до 
85% для очень больших проектов. Предположив что-то среднее, будем 
считать, что риск неудачи проекта 40% в случае плохого отслеживания 
его хода. Только улучшение отслеживания проекта снизило бы этот риск 
до 20%. Если результаты тестирования привносят только половину этой 
цифры вулучшение отслеживания проекта, то группа тестирования отве- 
чает за 10%-ное снижение риска неудачи проекта за счет оценки и про- 
гнозирования уровня качества системы и предоставления этой информа- 
ции группе управления проектом. 

Насколько значимо для проекта 10%-ное снижение риска? Это зави- 
сит от проекта. Если мы говорим о проекте стоимостью в миллион долла- 
ров, то это $100 000. (Заметьте, что мы снова применяем расчет ожидае- 
мых выплат, как описано выше.) Эта цифра, очевидно, представляет 
грубую оценку. Даже Джоунз предупреждает о большом разбросе цифр, 
на которые он ссылается. Однако мое мнение о цифрах возврата вложе- 
ний, полученных на основе предположений Джоунза, таково, что они 
обычно недооценивают значение результатов тестирования. 

Вконечном счете, информация, которую может предоставить группа 
тестирования в ходе доведения результатов оценки качества, имеет ис- 
ключительное значение для компании. Я подозреваю, что значение 
этой информации может превышать значение информации, представ- 
ленной в виде обнаруженных и исправленных до выпуска версии дефек- 
тов, поскольку она позволяет руководству принимать решения о рисках 


Более подробно о сборе, интерпретации и передаче результатов тестирования см. в гла- 
ве 15. Также можно обратиться к главам 4 и 5 книги “Мапарте іће Тезйпр Ртосеѕѕ, Зесопа Еайіст". 


? эта информация впервые появилась в "Райеті т Ѕоўйоате бузієт Кайите апі 5иссезз”. В главе 
7 книги “Езётайте Зойшате Соя" резюмируются результаты работы Джоунза. Оставшиеся 
три причины — это неточная предварительная оценка затрат, плохое планирование и не- 
достаточное тестирование. Что касается влияния этих причин, особенно последней, они 
уже рассматривались выше, 
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говорить о деталях. Если вы намерены утверждать, что любая ошибка, под- 
лежащая обязательному устранению, стоит $1500, если ее нашли в процес- 
се эксплуатации системы, потрудитесь объяснить, почему. 


Джамал готовится выставить счет. 
и его обоснование 


Изучив вопрос о возврате вложений в тестирование, Джамал вернулся 
к подготовке бюджета группы тестирования. Вооружившись декомпози- 
цией работ, Джамал взялся в первую очередь за кадровые вопросы. Он ре- 
шил использовать стратегию назначений в группе тестирования, осно- 
ванную на планеграфике проекта. Таким образом, Лин Цу, Эмма, новый 
тестировщик и новый лаборант будут назначены в проект на полную за- 
грузку, как только они должны будут приступить к своим обязанностям со- 
гласно планутрафику!. Поскольку у Джамала есть другие обязанности, 

в частности следить за тем, что тестирование версии сопровождения для 
других продуктов идет достаточно быстро, он выделил себе 50%-ную за- 
грузку в проекте. Он также предусмотрел расходы на командировку, по- 
скольку собирался нанести визит в лабораторию тестирования локализа- 
ции, которая находится в другом штате. 

Пока Джамал думал о лаборатории локализации, он вспомнил, что, 
проводя анализ покрытия, он отправил электронное сообщение коллеге, 
с которой познакомился на конференции по тестированию. В письме он 
спрашивал ее о квоте тестирования удобства использования. Он включил 
эту квоту в бюджет. Джамал не был уверен, что группа тестирования смо- 
жет провести тестирование удобства использования, поскольку очень 
большая часть функционального тестирования будет автоматизирована. 
(Будучи весьма эффективным, автоматизированное функциональное тес- 
тирование часто означает, что тестировщики имеют меньше времени на 
то, чтобы “потрогать руками” взаимодействие функциональных областей 
системы, что является ключевым при поиске проблем удобства использо- 
вания.) Более того, ни один человек в группе тестирования не имеет дос- 
таточного представления об удобстве использования. Конечно, он всегда 
обращается к тестировщикам с просьбой “влезть в шкуру разумного поль- 
зователя” при выполнении тестов, но это нето же самое, что иметь соот- 
ветствующего эксперта. 

Исследуя аппаратное обеспечение для тестовой среды, он включил 
в список новые серверные кластеры (мер-сервер, сервер приложений 
и сервер баз данных), а также 10 новых рабочих станций. Что касается 
программного обеспечения, ему также требуются лицензии для серве- 
ров, но это обычно не нужно включать в бюджет, поскольку ЗоЁмаге 
Саѓеегіа уже имеет достаточно лицензий по договорам с различными 
производителями программ. Наконец, по инструментарию Джамалу тре- 
бовалась еще одна лицензия на инструменты автоматизации тестирова- 


См. главу 8 моей книги “Мапартр їће Тезётв Ргосезз, Ѕесопа Её от”. 
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ния графического интерфейса и нагрузочного тестирования, погтому он 
добавил эти две лицензии в список. 


№ этапа Этап у Выполнено? 


2.А. Извлечение из декомпозиции работ полного списка ресурсов. Ы 
Определение для каждого ресурса первого и последнего дня 
работы в проекте. В случае если есть ресурсы, занятые сразу в 
нескольких проектах, уточнить процентную загрузку каждого 
из таких ресурсов в каждом из проектов в течение различных 
периодов времени. 


2.В Выявление необходимых дополнительных ресурсов для под- 
держки ресурсов, занятых сразу в нескольких проектах. 


2.С Распределение ресурсов по категориям: персонал, команди- ы 
ровки, инструментарий, тестовая среда и, если есть, затраты 
. на аутсорсинг. Суммирование по периодам времени и катего- | 
риям. 


Джамал посмотрел на первый черновик своего бюджета и понял, что 
забыл добавить 20% на непредвиденные обстоятельства, что было его 
обычной практикой. С этой добавкой общий бюджет тестирования соста- 
вил более $800 000 (см. рис. 4.2). По сравнению с предыдущими проекта- 
ми он был довольно велик. Однако он посмотрел на среднемесячные за- 
траты, которые составили $119 000. Эта цифра оказалась лишь чуть 
больше, чем в предыдущих проектах. “Это просто еще одно проявление 
раннего вовлечения тестировщиков в проект и более интенсивного тес- 
тирования в случае инкрементного подхода к разработке”, — думал он. 


Рис. 4.2. Первый черновик бюджета тестирования 
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Джамал не видел бюджета Дженни, но он знал, что в ее группу назначены 
П программистов и два менеджера. При средней ставке технического пер- 
сонала с учетом всех затрат в $120 000 в год только затраты на персонал раз- 
работчиков примерно равен всему бюджету Джамала. Просматривая неко- 
торые ранее выполненные бюджеты разработки, он прикинул, что Кейт 
ожидает, что его бюджет будет в пределах от одной четверти до одной трети 
всего бюджета проекта. “Я намереваюсь слегка превысить верхнюю грани: 
цу”, — думал он, поэтому мне следует подготовиться к защите бюджета. 


№ этапа Этап Выполнено? 


2р Проверка, с точки зрения здравого смысла, бюджета и общих М 
сумм. По возможности сопоставить профессиональные зна- 
ния и интуицию с данными предыдущих проектов, измерения- 
ми в отрасли и т.д., выявить и, если возможно, разрешить рас- 
хождения между бюджетом подпроекта тестирования и об- 
щим бюджетом проекта. Там, где это невозможно, документи- 
ровать проблемы. 


Первым шагом решения этой задачи могла бы стать количественная 
оценка возврата вложений в тестирование. Просматривая бюджет, он пони- 
мал, что сможет амортизировать инструментарий и экземпляры тестовых 
сред в течение следующих 18 месяцев, в течение которых будут выполнены 
три проекта, включая нынешний. Кроме того, он предполагал списать рабо- 
ты по созданию тестов и конфигурированию оборудования для тестирова- 
ния, каждая из которых потребует около двух человеко-месяцев работы 
Эммы, Лин Цу и нового тестировщика. Это составило бы около $60 000, 
и Джамал исключил бы все, кроме $20 000, из анализа возврата вложений. 


№ этапа Этап Выполнено? 
2.Е Уточнение амортизации объектов, которые являются предме- 


том долговременных инвестиций, документирование возмож- 
ностей их повторного использования и определение периода, 
в течение которого планируется возместить затраты. 


Чтобы проанализировать возврат вложений для обнаруженных и ис- 
правленных ошибок, Джамалу необходима оценка числа ошибок. У него 
нет точных данных о размере системы, например о количестве строк кода 
или функциональных точек, поскольку Зоймаге Саѓегегіа не пользуется та- 
кой статистикой. Тем не менее после некоторого исследования ранее вы- 
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полненных проектов и базы ошибок периода эксплуатации он выяснил, 
что в среднем в системе обнаруживалось 35 ошибок на человеко-месяц ра- 
боты программиста, что включало ошибки, найденные как в ходе тестиро- 
вания, так и после выпуска версий. В проекте «Суматра» запланировано 
75 человеко-месяцев работы программистов. Чтобы оценка была умерен- 
ной, Джамал принял 2500 за ожидаемое число ошибок. Поскольку пример- 
но 80% ошибок будут исправлены в ходе жизни проекта, он запланировал, 
что 2000 ошибок подлежат обязательному исправлению. 

Из предыдущих проектов Джамал знал, что в среднем группе тестирова- 
ния удается найти около 80% таких ошибок в системе. (Пользователи обыч- 
но находят оставшиеся 20% и сообщают о них группе технической поддерж- 
ки.) Он надеялся, что удастся сработать лучше в новом, не столь спешном 
режиме, но он решил не учитывать эти ожидания в анализе возврата инве- 
стиций. Таким образом, планировалось найти 1600 дефектов, подлежащих 
обязательному исправлению. Для быстрой проверки он умножил это число 
на средние затраты на обнаруженную ошибку, подлежащую обязательному 
исправлению, в его предыдущих проектах — $500. Он с радостью обнаружил, 
что цифры совпали. Таким образом, можно было считать, что будет обнару- 
жено 1600 ошибок, подлежащих обязательному исправлению. 

Цифра $500 на ошибку, подлежашую обязательному исправлению, 
учитывает все инвестиции в тестирование и затраты на обнаружение 
ошибок и затраты на внутренние несоответствия, связанные с тестирова- 
нием. Теперь Джамал решил подсчитать средние затраты на внутренние 
и внешние несоответствия для дефектов. 

Чтобы подсчитать затраты на внутренние несоответствия для группы 
тестирования, он сначала оценил повторное тестирование. Он заплани- 
ровал 11 тестовых раундов. В шести из них будет проверяться новая функ- 
циональность в рамках очередного инкремента. Следовательно, пять тес- 
товых раундов будут посвящены повторному тестированию для проверки 
исправления ошибок и регрессии. Продолжительность тестирования 
определена в 22 недели. На основе этих расчетов затраты на персонал на 
неделю тестирования примерно равны $17 000. Это означает, что суммар- 
ные затраты на тестирование внутренних несоответствий составляют 
примерно $170 000, причем затраты на тестирование для каждой ошибки, 
подлежащей обязательному исправлению, равны $105 (см. рис. 4.3). 

Что касается разработки, Джамалу было известно от Дженни, что вте- 
чение 22 недель тестирования она планирует, что половину времени 
группа тестирования будет тратить на исправление ошибок, а другую по- 
ловину на работу над новыми свойствами очередного инкремента. Ис- 
пользуя среднюю ставку в $120 000 в год на 13 человек группы разработки, 
Джамал получил $215 затрат разработчиков на работу с одним дефектом, 
подлежащим обязательному исправлению. Таким образом, полные затра- 
ты на внутренние несоответствия на дефект достигают $320. 

После выпуска версии в продажу затраты переносятся на программи- 
; стов сопровождения, которые будут исправлять ошибки и усовершенст- 

вовать программу, и на сотрудников группы технической поддержки, ко- 
„торые будут отвечать на звонки, относящиеся к ошибкам в системе 
:ги. ошибкам пользователей. Из разговоров с менеджерами этих подразде- 
- лений Джамалу было известно, что около 75% времени в каждой группе 
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Рис. 4.3. Подсчет затрат на внутренние и внешние несоответствия в проекте 
с » 
Суматра”) 


тратится на работу с ошибками системы. После выпуска версия поддер- 
живается в течение года. Основываясь на размерах групп и ставках персо- 
нала, Джамал смог оценить затраты на внешние несоответствия в $1404 
на один дефект, подлежащий обязательному исправлению. 

Таким образом, каждая ошибка, подлежащая обязательному исправ- 
лению и обнаруженная в ходе тестирования, экономит компании при- 
мерно $1084. Подставляя в уравнение стоимости качества, получаем 
прибыль в размере около 1.7 миллиона долларов. “Неплохо, — подумал 
он, — мы уже в плюсе при возврате вложений в тестирование, а еще не 
все подсчитано”. 

Теперь рассмотрим оставшиеся 500 (или около того) найденных и не 
исправленных ошибок. Обычно около трети — это ошибки тестировщи- 
ков, ошибки в конфигурации системы и другие проблемы, не являющиеся 
ошибками системы. Остается примерно 300 ошибок, являющихся действи- 
тельно проблемами системы, которые по разным причинам были отложе- 
ны. В результате обсуждения с менеджером группы поддержки пользовате- 
лей Косимо Неграевым выяснилось что, наличие информации об этих 
ошибках в базе знаний группы поддержки обычно экономит до 15 минут на 
звонок. Более того, Косимо упомянул, что на каждую ошибку в системе 
обычно приходится пять звонков. Снова используя среднюю ставку в $120 
000 в год, Джамал получает $60 в час. Таким образом, выигрыш по обнару- 
женным, но неисправленным ошибкам составляет примерно $25 000. 

Далее Джамал обратил внимание на значение снижения риска. В про- 
цессе анализа рисков качества участники определили вероятность воз- 
никновения проблем как очень высокую в следующих категориях рисков 
качества: 


и Нагрузка, производительность, объем 
= Надежность и стабильность 
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Из разговора с Мухаммедом Аджами, отвечающим за продажи компа- 
ниям Еогипе 1000 и государственным организациям, Джамал узнал, что 
проблемы в этих областях системы могут обойтись, по крайней мере, 
в 2 миллиона долларов дохода от продаж. Крупные заказчики наиболее 
болезненно воспримут эти проблемы и не будут их терпеть. Сучетом 50%- 
ной вероятности проблем такого рода снижение риска только их возник- 
новения с помощью тестирования принесет 1 миллион долларов. 

Наконец, Джамал рассмотрел прибыль, которую приносит отслежива- 
ние хода проекта. Прочитав книгу Джоунза, он решил воспользоваться 
эмпирическим правилом “10% бюджета проекта”. Очень грубая оценка 
его доли бюджета проекта в 40% дает общую стоимость проекта 2 миллио- 
на долларов. Информация о проверке системы и прогнозы, которые 
группа тестирования планирует предоставлять группе управления проек- 
том, снижая риск неудачи проекта на 10%, приносит $200 000 прибыли. 

Таким образом, Джамал получил суммарный доход от предлагаемой 
им программы тестирования примерно 3 миллиона долларов, 350% воз- 
врата вложений втестирование (см. рис. 4.4). Хотя, согласно корпоратив- 
ным правилам боЁмаге Саѓегегіа, тест-менеджеру запрещено обсуждать 
цифры бюджета с сотрудниками группы тестирования, он чувствовал 
себя очень комфортно, сумев обосновать умеренный, но верный возврат 
вложений в тестирование в проекте. Он с нетерпением ожидал возмож- 


Рис. 4.4. Расчет возврата вложений в тестирование для первого варианта 
! бюджета Джамала 
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ности представить обоснование бюджета руководству проекта. Он был 
счастлив получить разрешение двигаться дальше. 


№ этапа Этап Выполнено? 
2.Е Если это необходимо или желательно, провести анализ воз- 


врата инвестиций. Если сальдо отрицательное, проверить до- 
пущения об амортизации, сделанные на шаге 2.Е, и при необ- 
ходимости повторить его. Если сальдо по-прежнему отрица- 
тельное, проанализировать те компоненты декомпозиции ра- 
бот, которые требуют наибольших затрат с наименьшей отда- 
чей, сверившись с рисками качества. Документировать актив- 
ности, приводящие к потере средств. 


2. Использовать декомпозицию работ и план-график для подго- м 
товки бюджета. 


связанные: с ВОЗМОЖНОСТЯМИ. распознавания. ‘почерка: «Так случилось, ‹ 

один из экземпляров Мемлоп. приобрел Гарри Трюдо (Сау Тгидеац), ав 
‘тор комиксов “Ооопеѕригу”, печатающихся во многих изданиях Северно 
| ИК 4 Он высмеивал слабости: в распознавании почерков в. Мема 


- вали ( ‘бы. ситуацию; буд я лидером ва пека 
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Двигаясь вперед, оглянись назад 


В этой главе очерчен, а затем показан на примере Джамала способ транс- 
формирования декомпозиции работ в бюджет и анализа возврата вложе- 
ний, соответствующего предлагаемым затратам на тестирование. Теперь 
читатель получил обоснованную оценку времени и ресурсов, направлен- 
ных на контроль критических рисков качества, наряду с обоснованием 
выбранных действий не только в терминах качества, но и с точки зрения 
финансов. Остается только положить весь пакет полученных документов 
на стол менеджера проекта и ожидать положительной оценки деловой 
хватки и немедленного предоставления всех запрошенных ресурсов, не 
так ли? К сожалению, обычно это далеко не так. 

В следующей главе мы завершим обсуждение оценок и перейдем к про- 
цессу обсуждения бюджета. Подготовлено сильное предложение, но его 
еще нужно “продать” руководству. Надо убедить их захотеть приобрести 
предлагаемые вами продукты и услуги по управлению рисками качества 
и преодолеть неизбежные возражения относительно сроков их предос- 
тавления и соответствующих затрат. После завершения обсуждения бюд- 
жета будет показана ретроспектива процесса оценки затрат. Прежде чем 
перейти к разработке планов тестирования, мы должны посмотреть на 
показатели хороших оценок затрат на тестирование, проблемы при под- 
готовке таких оценок и планы развития системы, которые можно приме- 
нять для продвижения процесса оценки затрат. 


ГЛАВА 5 


От оценки затрат к базовой 
версии: получение одобрения 
реалистичных, работоспособных 
и правдивых оценок | 


В этой главе завершается обсуждение оценки затрат на проект тести- 
рования. Сначала мы посмотрим на то, что является, по всей веро- 
ятности, самым сложным этапом процесса — на получение одобрения 
подготовленных оценок затрат у руководства. Чтобы уговорить менед- 
жеров выделить время и деньги на достойное тестирование, необходи- 
мы доверие и дар убеждения. Правдоподобные оценки и убедительное 
описание бизнес-плана являются ключевыми частями решения пробле- 
мы. Этапы, показанные в двух предыдущих главах, дают некоторые идеи 
о том, как получить эти части. Однако, когда вы представляете оценки 
руководству проекта, проверке подвергаются только ваш политический 
капитал и навыки. 

После завершения исследования этого непростого процесса мы снова 
посмотрим на весь процесс оценки затрат. Как узнать, что оценка затрат 
сделана успешно? Какие факторы способствуют получению хороших оце- 
нок? Какие проблемы существуют? И как можно ввести в практику более 
удобные и эффективные методы оценки затрат? Ответы на эти вопросы 
будут даны во второй части главы. 


“Продажа” оценки затрат 


Получение хорошей, надежной оценки, включая окупаемость вложе- 
ний, — непростая задача, получение поддержки руководства — задача 
другого рода. Даже наилучшая оценка затрат подпроекта тестирования 
с наиболее основательным бизнес-планом может столкнуться с препят- 
ствиями. Некоторые из этих препятствий заставят уменьшить исходные 
границы тестирования. Иногда этому нет альтернативы, поскольку ком- 
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пания действительно не может позволить себе покрыть все риски каче- 
ства системы, которые в ходе анализа рисков определены как важные. 
Итак, рассмотрим некоторые из препятствий, с которыми мы сталкива- 
емся, а затем исследуем, какими способами их можно преодолеть. 

Позвольте начать с препятствий, которые мы создаем сами как тести- 
ровщики. Мы обычно смотрим на тестирование и качество как на дейст- 
вительно важные вещи. За годы работы некоторые постулаты, связанные 
с тестированием и качеством, стали настолько очевидными для нас, что 
это оказывает влияние на способность взаимодействия с теми людьми, 
которые не смотрят на проект теми же глазами. В список этих людей по- 
падают менеджеры, которые принимают решение о бюджете тестирова- 
ния. В результате мы не можем разговаривать с руководителями на одном 
языке. Как пишет Джеймс Баллок (Јатеѕ ВиПосЮ): “Когда мы пытаемся 
обосновать тестирование, то часто приводим аргументы, исходя из не- 
верного представления, что тестирование — это самое правильное, что нуж- 
но делать" . 

Мы рассматриваем тестирование как важную часть разработки каче- 
ственного продукта. Однако значение тестирования не всегда очевидно 
менеджеру. Это особенно верно в том случае, когда менеджер видит, что 
предлагаемый бюджет съедает существенную часть денег, необходимых 
на весь проект, а график тестирования откладывает дату выпуска про- 
дукта. Еще хуже, когда некоторые тестировщики реагируют на пробле- 
мы, связанные с потребностью тестирования, исходя из того, что ни- 
кто, кроме них, не отстаивает качество системы. Такое отношение 
оказывает непоправимый вред их усилиям по подготовке и защите бюд- 
жета тестирования. 

Чтобы эффективно взаимодействовать с менеджером проекта и стар- 
шими менеджерами, я пытаюсь увидеть, как тестирование встраивается 
в объемлющий проект. Не считая себя единственным сторонником ка- 
чества, я обрисовываю свою роль как специалиста по тестированию. 
Я оказываю помощь моим коллегам по управлению рисками качества 
системы, которую мы разрабатываем, сопровождаем или поставляем. 
Какие из услуг управления рисками качества и сведения о рисках имеют 
ценность для моих коллег? Могу ли я думать о способах передачи инфор- 
мации о том, почему указанные продукты и услуги будут для них более 
ценными, чем им кажется, в терминах, которые поймут мои менедже- 
ры? Могули яубедить людей в необходимости тестирования сточки зре- 
ния бизнеса? 

Как только вы начинаете смотреть на тестирование в более широком 
контексте, реалии бизнеса в тестировании становятся яснее, раскрывая 
следующую группу препятствий. “Хорошо, — может сказать старший ме- 
неджер, — тестирование полезно, но посмотри, какие будут затраты и сро- 
ки”. В зависимости от проекта тестировщики составляют от 15 до 50% 
всего персонала. Тестовые среды, копирующие среду пользователя, что 
существенно для системного тестирования, могут быть большими, доро- 


Эта и другие мысли найдены В статье Джеймса Баллока «Сасшайля фе Уаїше ої Тез іп», 
опубликованной в “5оўћшате Тезїпр апі Оибійу Епріпеєтітр", Моїате 2, Іѕѕие 3 (Мау/)апе 2000) 
и доступной в настоящее время на муу.ѕйскутірдѕ.сот. 
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гими и трудными в сопровождении. Каждый тестовый цикл, кроме перво- 
го, откладывает поставку системы. Эти задержки возмущают руково- 
дство, поскольку для проектов время — деньги: опоздания с поставкой 

‚ означают штрафы по контрактам, упущенные возможности, связанные 
с несвоевременным выходом продукта на рынок и т.д. 

В некоторых компаниях менеджеры высшего звена могут увидеть по- 
литический ущерб в предложении отложить сроки или увеличить бюд- 
жет. Начальные план и бюджет, даже если они выглядят скороспелыми и 
скудными для тестировщиков и других сотрудников, выполняющих ре- 
альную работу, могут быть обеспечены только при условии наличия здра- 
вого смысла у части группы управления проектом. Меня беспокоит вари- 
ант, когда менеджер проекта начинает свирепеть при защите разумных 
вложений в тестирование. Я понимаю, что мне нужно предвидеть зара- 
нее, будет ли моя оценка затрат, если ее утвердят, вынуждать руководство 
проекта вновь открывать дискуссию о сроках и бюджете проекта. Если 
это так, я добавляю дополнительные обоснования, чтобы не допустить 
новых изменений. і 

Большинство менеджеров проектов — это опытные профессионалы. 
Они обычно находятся в гуще системных проектов и могут вспомнить 
плановую короткую фазу тестирования, которая увеличилась на неделю, 
потом на две, потом на четыре и так далее, каждый раз усиливая паниче- 
ские настроения. Следовательно, опытный менеджер проекта будет изу- 
чать план-график и бюджет в поисках того, что ему нужно: заниженные 
ограничения, минимальные вложения в тестирование, небольшая на- 
чальная цена. 

“Подождите, — скажете вы, — не вы ли всю прошлую главу рассказыва- 
ли о том, что разумно проводимое тестирование дает положительное 
сальдо на инвестиции в него? И о том, что качество бесплатно?” Да. Но 
это верно лишь в долгосрочной перспективе, в ходе всего жизненного 
цикла системы. В то же время затраты на разработку, сопровождение 
и поставку системы обычно финансируются, исходя из проекта, а не из 
жизненного цикла системы. На любой проект выделяется ограниченный 
объем средств. Следовательно, с одной стороны, инвестиции в тестиро- 
вание имеют положительное сальдо, но, с другой стороны, они также 
представляют, как и любые инвестиции, неизбежные расходы. 

В некоторых случаях мы должны убеждать менеджеров, которые не 

- разбираются в тестировании или не знакомы с успешно идущими проек- 
тами тестирования. Это порождает дополнительные препятствия для по- 
лучения одобрения бюджета руководством. Во-первых, нам приходится 
знакомить менеджеров с тем, в чем ценность тестирования для проекта. 
Во-вторых, у нас мало времени, чтобы это сделать, поскольку большинст- 


1 В 1975 г. Фред Брукс (Егей Вгоок5) писал в “Мифическом человеко-месяие”: «Особенно ката- 
строфические последствия может иметь недостаток времени для системного тестирования. 
Поскольку задержка происходит в конечной части графика, никто не подозревает о том, 
что график находится под угрозой срыва вплоть до дня сдачи продукта. Плохие вести, полу- 
ченные поздно и без предупреждения, обескураживают менеджеров и имеют особенно тя- 
желые материальные и психологические последствия. Проект осуществляется при полной 
укомплектованности работниками и максимальных финансовых издержках. Еще важнее, 
"что вторичные издержки могут быть выше, чем все прочие. Поэтому очень важно в изна- 
чальном графике работ отвести достаточно времени для системного тестирования». 
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во менеджеров проектов заняты на бесконечных совещаниях, где они за- 
нимаются тем, что вводят друг друга в заблуждение. В-третьих, некото- 
рые тест-менеджеры считают трудным объяснение особенностей 
и реальностей тестирования людям, которые не знакомы с кухней проек- 
та тестирования. Как тестировщики-профессионалы мы сконцентриро- 
ваны на растущей, изменяющейся и приводящей нас в восхищение про- 
фессии в рамках разработки системы. Это означает, что многие из наших 
коллег, включая тех, кто руководит нами и утверждает наши запросы ре- 
сурсов, не могут уследить за всеми изменениями в теории и практике тес- 
тирования. В результате они часто не могут понять детали того, что мы 
делаем и почему это делаем, или, другими словами, динамику процесса 
тестирования. 

Как можно преодолеть эти препятствия? Ответ зависит от конкрет- 
ной ситуации, поскольку это вопрос, связанный исключительно с “прода- 
жей” бюджета. Как продать что-нибудь? Это зависит не только от продук- 
та или услуги, но и от покупателя, а все они разные. Однако весь процесс 
прост: сделать продукт или услугу желанными для человека, которого вы 
пытаетесь убедить потратить деньги, а затем работать с его возражения- 
ми. Я обычно использую следующий метод. 

Сначала я пытаюсь продать мои оценки на основе рисков. Опираясь 
на основательный анализ рисков качества, я могу создать мощную защи- 
ту своих предложений, поскольку могу увязать их с вопросом отом, что 
могут означать для бизнеса проблемы в период эксплуатации. Каждая за- 
дача в плане-графике, каждый доллар в бюджете сопоставляется опреде- 
ленному критическому риску качества. Что я стараюсь сделать, так это 
показать очевидную ценность тестирования: “Если мы беспокоимся об 
этом риске, вот сколько будет стоить его смягчение с помощью тестиро- 
вания”. Опишите в общих чертах катастрофические последствия для 
прибыли, целей компании, даже жизни, которые можно предотвратить 
до выпуска версии, особенно для дорогих бюджетных единиц, напри- 
мер серверов или сотрудников. Не втянута ли компания-конкурент или 
другая компания, работающая в аналогичной отрасли и развернувшая 
похожую систему, в судебные разбирательства из-за проблем качества 
системы? 

Кроме того, поскольку я прошу кусок уже готового и неизменного пи- 
рога — часть бюджета всего проекта, который часто зафиксирован к это- 
му моменту, - я не могу делать это в вакууме. Если я попытаюсь это сде- 
лать, то ничего не выиграю в соревновании с менеджерами моего уровня. 
Таким образом, часть моего метода продажи включает в себя поиск союз- 
ников. В главе 1 говорилось о проблемах выстраивания крепких взаимо- 
отношений с внутренними заказчиками: программистами, сотрудниками 
отделов продаж и маркетинга, специалистами по поддержке пользовате- 
лей, сетевыми администраторами. Сейчас подходящий момент для ис- 
пользования этих отношений. Определите конкретные способы, кото- 
рыми бюджет поддерживает услуги и продукты для нужд заказчиков. 
Определите, какие из этих продуктов и услуг вы не сможете поставить 
в случае урезания бюджета. Попросите ваших коллег о поддержке. Не за- 
бывайте также о человеческих аспектах при получении поддержки. Но- 
скольку тестировщики исполняют роль поставщиков услуг, они должны 
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обладать точкой зрения, ориентированной на предоставление услуг. 
Я прилагаю усилия к тому, чтобы выстроить партнерские позитивные 
взаимоотношения с людьми из проектной группы, дабы быть уверенным 
в том, что группа тестирования и ее работа рассматриваются как поддер- 
живающий и положительный фактор для успеха проекта. 

Также я использую результаты анализа инвестиций. В то же время я не 
ограничиваюсь только демонстрацией цифр. Если я приведу цифры: “Мы 
намерены получить 375% окупаемости вложений на тестирование”, —это 
прозвучит не очень убедительно. Это лишь краткое заключение, требую- 
щее подробных пояснений, как получена цифра и что она означает. 

Для пояснения окупаемости вложений я выхожу за рамки сухих такти- 
ческих категорий — обнаружение дефектов, поддержка устранения де- 
фектов, снижение рисков и управление проектом, чтобы увязать этот во- 
прос с тем, почему менеджеры вкладывают деньги в тестирование. 
Например, насколько предлагаемый подпроект тестирования позволяет 
компании снизить общие затраты на систему, связанные с проблемами 
качества? Какую степень доверия к надежности эксплуатации системы 
мы можем гарантировать руководству? Не бойтесь также говорить о не- 
материальных активах компании. Как раз потому, что вы не можете коли- 
чественно оценить их, спрашивайте менеджеров, насколько будет выгод- 
но улучшить репутацию компании за счет повышения качества системы. 
Насколько выгодно снижение хаоса, повышение морального духа и сни- 
жение текучести персонала? 

Разумные менеджеры проектов часто отвечают на эти замечания: “Да, 
мне нужны преимущества тестирования, но почему они так дороги и тре- 
буют столько времени?” Это как раз тот момент, когда нужно уметь четко 
разъяснить план проекта тестирования, тему предыдущих двух глав. 
Наша способность объяснить логику и взаимосвязи между тестировани- 
ем и остальной частью проекта позволяет менеджерам увидеть пробле- 
мы, с которыми мы сталкиваемся при тестировании. Кроме того, мне 
нужны данные за продолжительный период времени, лучше о похожих 
проектах, чтобы показать, почему требуется примерно столько времени, 
насколько я оцениваю усилия группы проекта по поиску и устранению 
важных ошибок. 

В некоторых случаях присутствует излишний оптимизм в отношении 
качества системы, проецируемый на тестирование и общий ход проекта. 
В этих случаях я считаю, что сокращение утвержденного графика тестиро- 
вания и урезание утвержденного бюджета тестирования может в кратко- 
срочной перспективе показатьуменьшение времени и затрат на тестиро- 
вание. Однако сокращение адекватной проверки качества на самом деле 
увеличивает риск превышения бюджета и нарушения сроков проекта, 
часто очень значительно по отношению к реалистичным бюджету и сро- 
кам, которые были выработаны в начале проекта. Дефекты, обнаружен- 
ные на ранних стадиях проекта за счет эффективного и целесообразного 


1 В забавной книге Дугласа Адамса (Доиріаз АЧат5) “Тйе НисМийегз Сиійе іо ће Сааху' ком- 
пьютер вычисляет значение жизни, равное 42. Этот результат обманывает и разочаровыва- 
ет людей, которые запрограммировали компьютер, чтобы узнать, что такое жизнь. Меняю- 
щееся значение окупаемости инвестиций может в равной степени ввести в заблуждение 
ваших менеджеров. 
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тестирования (включая статическое тестирование требований, архитек- 
туры и просмотр кода), могут быть легко и дешево устранены с незначи- 
тельным влиянием на сроки и бюджет проекта. Однако серьезные ошиб- 
ки, обнаруженные в последние две недели, могут иметь фатальные 
последствия. 

Применяя свой метод “продажи” бюджета, я предпочитаю выступать 
в роли адвоката, а не понтифика. Если я общаюсь с менеджерами, непони- 
мающими тестирования и скептически относящимися к бюджету и графи- 
ку, мне нужно мобилизовать силы и выдвинуть в качестве предложения по- 
ложительный и убедительный вариант. Я могу быть эмоциональным, но 
избегаю поучений. Продавая оценку затрат, я считаю, что несу свет знаний 
в массы коллег, старших и высших руководителей. Если я найду правиль- 
ные мотивы для них или, другими словами, сделаю желаемым то, что я про- 


даю, они захотят понять, что я предлагаю. з 


Джамал готовит свой вариант 


В пятницу во второй половине дня, завершив оценку затрат, Джамал по- 
звонил своему боссу, вице-президенту поддержки разработок Джону Ал- 
бертсону. “Привет, Джон, — сказал он. — Я почти готов к обсуждению 
стобой предложений по графику и бюджету тестирования Суматры в по- 
недельник. Есть ли у тебя время с утра?”) 

“Конечно, — ответил Джон, — я записываю тебя на 10.00”. 

Джамал отправился на поиски менеджера продукта 5реедуУУгіїег Кейт 
Эрнандес с копиями графика и бюджета. “Привет, Кейт, есть минутка?") 

“Да, заходи, что у тебя?”) 

“Вот, — сказал Джамал, — у меня примерный план-график и оценка 
бюджета тестирования, которые я собираюсь предложить для проекта. 
Думаю, что должен тебе их показать”. Он быстро разложил перед Кейт 
различные активности, затраты и анализ окупаемости инвестиций. “На 
основе этого бюджета и графика, я думаю, мы сможем вести действи- 
тельно тщательное тестирование и предоставлять тебе очень точные 
данные о состоянии проекта и о том, как он идет, на еженедельных сове- 
щаниях”. 

Кейт почесала затылок. “Это больше, чем я думала. Я смотрела преды- 
дущие проекты и решила, что полмиллиона на тестирование И доста- 
точно”. 

“Да, но те подпроекты тестирования продолжались только 4-5 меся- 
цев. Наши среднемесячные затраты лишь немногим больше, чем в преды- 
дущих проектах. Я нанимаю в основном лаборантов-контрактников для 
экономии расходов”. 

После непродолжительного обсуждения Кейт согласилась посмот- 
реть, сможет ли он частично урезать бюджет группы маркетинга и бюд- 


1 Несколько других идей о том, как продавать тестирование руководству, можно найти 
в статье Джеффа Пэйна (Је Раупе) “Оца#у Меєтіз СЕО", которая была впервые напечатана 
в журнале "5о/їшате Теѕйпр спі Оца у Епріпеетіпр", Уопиие 1, 554е3 раа 1999), а сейчас 


доступна на муу.5іскушіпаѕ.сою. 
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жет разработки Дженни Кауфман для частичного возмещения избытка 
в $300 000. Оставшуюся сумму она пообещала поискать вместе с гене- 
ральным директором Раджешем и вице-президентом по маркетингу 
Максом. 

Возвращаясь в свой кабинет, Джамал сделал остановку у кабинета 
Дженни, чтобы показать график и бюджет на верхнем уровне детализа- 
ции и предупредить ее о возможном урезании бюджета группы разработ- 
ки. Дженни не сильно обрадовалась уменьшению бюджета, особенно ко- 
гда поняла, что это может выразиться в потере одного сотрудника. 
Джамал предложил заключить сделку, выразив желание принять участие 
в разработке тестов для компонентного тестирования. “Слушай, нам 
тоже нужны эти тесты, Дженни, поэтому не будет проблем, если мы разра- 
ботаем вместе с твоими ребятами некоторые из них”. 

“Знаешь, — сказала Дженни, — это, возможно, даст лучшие результаты. 
Мы сможем воспользоваться поддержкой специалистов при создании 
и выполнении тестов”. 

Поучаствовав еще немного в светской беседе, Джамал пошел к себе, 
спросив, уже уходя, Дженни, не может ли она сообщить Кейт уже сегодня, 
что в целом поддерживаєт оценки графика и бюджета. Дженни согласи- 
лась подготовить и отправить короткое сообщение по итогам обсужде- 
ния с Джамалом, в частности, упомянув, что она не возражает против не- 
большого уточнения бюджета ее группы с учетом того, что группа 
тестирования окажет ей дополнительную помощь при подготовке и про- 
ведении компонентного тестирования. 

В понедельник утром Джамал отправился на встречу с Джоном. В до- 
полнение к основательным оценкам затрат Джамал решил опираться на 
свою репутацию склонного кнедооценкам, надежного и заслуживающего 
доверия менеджера. Когда он пришел, вице-президент по системной раз- 
работке Гарольд как раз завершал разговор с Джоном. “Доброеутро, Джа- 
мал! — приветствовал его Гарольд. — Рад тебя видеть. Дженни сообщила, 
что вы вдвоем обсудили примерные график и бюджет тестирования, 
а Кейт сказала, что у вас есть неплохой совместный план действий. Ты не 
против, если я поучаствую в обсуждении? Мне хотелось бы побольше уз- 
нать о твоих оценках”. 

Ни Джамал, ни Джон не возражали. Втроем они разложили таблицу 
анализа видов ошибок и их влияния, результаты анализа тестового по- 
крытия, график Гантта, таблицы с бюджетом и с описанием окупаемости 
вложений в тестирование на длинном столе в кабинете Джона и приня- 
лись за работу. Джамал начал с результатов анализа рисков качества и тес- 
тового покрытия, сказав: “Давайте сначала посмотрим на то, как я полу- 
чил эти оценки и какие риски мы собираемся снижать”. Он показал 
различные риски, включая комментарии, почему они имеют значение, 
и тестовые сценарии, которые их покрывают. В результате он перешел 
к декомпозиции работ, показав сопутствующие задачи. Затем он предста- 
вил бюджет и таблицу окупаемости инвестиций в тестирование. В ходе 
всего обсуждения Джон и Гарольд задавали различные уточняющие во- 
прось, но ничего не комментировали. Наконец Джамал сказал: “Итак, 
что вы думаете?”) 


128 


Часть І. Планирование 


№ этапа Этап | - Выполнено? 
3.А Презентация преимуществ подпроекта тестирования. 5 
3.В Обрисовать временные и финансовые ресурсы, необходимые И 


для получения описанных преимуществ. 


Кивнув, Джон сказал: “Я думаю, что ты проделал хорошую работу, по- 
лучив отлично документированную оценку затрат. Я также думаю, что ты 
организовал хорошую презентацию оценки. Но...”) 

“Я-то надеялся, что не будет никаких “но”)“, — отшутился Джамал. 

“Боюсь, что без них не обойтись. Гарольд, Кейт и я рассмотрели оцен- 
ку со всех сторон, и мне кажется, что мы не можем принять цифру 800К. 
Я думаю, что 700К более реально”. 

Джамал отвечал: “Могу урезать непредвиденные расходы, чтобы дать 
эту цифру, но не думаю, что это реально. Мы все равно в конце получим 
что-то около 20%, я просто не знаю, где взять еще”. 

Джон кивнул, а Гарольд вставил: “Знаешь, мне кажется, что непредви- 
денные расходы предназначены для покрытия непредвиденных сдвигов 
графика, не так ли? В нашем случае ты закладываешься на два дополни- 
тельных месяца финансирования персонала. С учетом того, что мы ис- 
пользуем итерационный подход, я думаю, ты мог бы сократить половину. 
Я уверен, что мы не отстанем больше чем на месяц”. 

“Звучит довольно привлекательно, — сказал Джамал, — при условии, 
что мы все соглашаемся, что, если график сдвинется больше чем на ме- 
сяц, нам придется выйти за пределы бюджета”. Джон и Гарольд согласи- 
лись. “Теперь нам нужно сэкономить еще $60 000, чтобы не выйти за $700 
000. Нам придется урезать часть тестирования”. 

“Что если не нанимать дополнительного тестировщика? Это даст поч- 
ти то, что нужно”. 

“В этом случае мне придется сдвинуть начало тестирования пример- 
но на месяц, и я думаю, что тогда мы не сможем выполнить договорен- 
ность С Дженни о помощи в подготовке и проведеним компонентного 
тестирования". 

"Хм, — заметил Гарольд, — это не очень хорошо. Мы очень на это рас- 
считываем”. 

“А что если сделать вот так? — предложил Джамал. — Вместо парал- 
лельного выполнения тестов на надежность и перегрузку на двух отдель- 
ных конфигурациях мы купим только один дополнительный сервер ибу- 
дем чередовать тестирование надежности и перегрузки через раунд? 
Это, конечно, создаст небольшой разрыв в регрессионном тестирова- 
нии, поскольку мы будем получать меньше информации о том, как каж- 
дая сборка влияет на надежность и производительность системы, но это 
позволит сэкономить $75 000, предназначенных на дополнительную тес- 
товую среду”. 

Гарольду и Джону очень понравилась эта идея. Джамалу тоже. Это на 
самом деле не только снизит затраты, но и позволит высвободить часть 
времени Эммы, поскольку ей не нужно будет каждый раз организовывать 
выполнение обоих комплектов автоматизированных тестов одновремен- 
но. Джон и Гарольд предложили Джамалу перейти к следующим этапам и 
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продолжить работу с данной оценкой. Джамал положил документы с 
планом-графиком и бюджетом в репозиторий проекта и мог теперь пере- 
ходить к разработке планов тестирования. 


№ этапа Этан Выполнено? 
3.С Осознание и принятие мер по разрешению любых возраже- м 
ний по поводу сделанных оценок посредством повторения ша- 
гов 3.А и 3.В. 
3.р Если не удается получить согласие руководства на предлагае- М 


мые план-график и бюджет, обсудить, какие области тестирова- 
ния могут быть исключены, установить, какие ограничения по 
срокам и бюджету позволят получить поддержку руководства. 


3. Утвердить у руководства план-график и бюджет. МІ 


4. Повторить этапы 1-3, если необходимо. Уточнить график работ И 
и бюджет с целью добиться адекватности ресурсов рамкам тести- 
рования (возможно уточненным) и одобрения руководства. 


5. Поместить принятые документы, фиксирующие план-график Ы 
и бюджет, в проектную библиотеку или систему управления 
конфигурацией проекта. Организовать контроль изменений 
документов. 


Построение успешного процесса оценки затрат 


В последних трех главах был представлен большой объем информации об 
оценке затрат. Возможно, читатель думает, что вся сложность процесса 
оценки затрат состоит в трудности построения грамотного процесса. Од- 
нако, немного попрактиковавшись, вы обнаружите, что это не так слож- 
но. Мы можем правильно построить процесс оценки затрат, посколькуон 
позволяет рабочей группе проекта делать следующее. 


Определение факторов, влияющих на оценку 


Системная разработка, сопровождение, поставка, включая тестирова- 
ние, — это сложные мероприятия с высоким риском. Важно комбиниро- 
вать полезные методы оценки затрат с пониманием факторов, которые 
влияют на затраты, сроки, зависимости и ресурсы. Некоторые из этих 
факторов могут и увеличить, и сократить сроки, тогда как другие все толь- 
ко замедляют. 

Некоторые из этих факторов вытекают из процесса выполнения работы: 


и Степень, в которой активности тестирования пронизывают про- 
ект или присоединяются в конце 


и Четко определенные точки передачи управления между тестирова- 
нием и остальной частью проекта или компании 


ш Число изменений в проекте, особенно при использовании авто- 
матизированных тестов или детально подготовленных тестовых 
скриптов для ручного тестирования 
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Хорошо управляемые процессы управления изменениями для гра- 
фиков разработки и тестирования, требований к продукту, архи- 
тектуры, разработки и тестирования 

Выбранный жизненный цикл системы, включая эффективность, 


производительность и степень организации процессов тестирова- 
ния и разработки в рамках жизненного цикла 


Реалистичные и работающие графики и бюджеты разработки 
и тестирования 


Своевременное поступление высококачественных передаваемых 
результатов тестирования 


Своевременное и надежное устранение обнаруженных дефектов, 
особенно при нарушении критериев начала тестирования 


Надлежащее проведение ранних фаз тестирования (модульного, 
компонентного, комплексного) 


Некоторые из факторов имеют материальную основу и обусловлены 
природой проектной работы, имеющихся инструментов, доступных ре- 
сурсов и т.п.: 


Наличествующие, освоенные высококачественные инструменты 
и средства автоматизации тестирования и процесса 


Качество системы тестов, под которой подразумеваются тестовая 
среда, процесс тестирования, тестовые сценарии, инструменты 
тестирования и т.п. 


Системы тестов и документация многократного применения из 
предыдущих похожих проектов 


Адекватная, отдельная и безопасная тестовая среда 
Отдельная, адекватная среда отладки у группы разработки 


Наличие надежного тестового оракула (как мы можем узнать ошиб- 
ку, когда видим ее) 


Доступная проектная документация высокого качества (понятная, 
лаконичная, точная и т.п.), в том числе требования, архитектура, 
планы и т.п. 


Похожие проекты и тестирование, выполнявшиеся ранее 


Некоторые факторы вытекают из особенностей состава группы тести- 
рования, и это, возможно, наиболее важные из всех: 


Надлежащие навыки, опыт и отношениек работе в проектной груп- 
пе, особенно у менеджеров и ключевых сотрудников, а также в обу- 
чении и поиске новых людей 


Организационные изменения, включая массовые реорганизации 
в середине проекта 

Чувство обиды и другие проблемы взаимоотношений в проектной 
группе 

Сверхурочная работа, работа по выходным и рабочие смены вне 
пределов основного рабочего времени 
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Усталость и моральные проблемы, особенно накопившиеся в пре- 
дыдущих проектах 

Корпоративная культура и привычки 

Компетентность и опыт группы управления проектом 


Вдохновляемые и вдохновляющие менеджеры и технические лиде- 
ры, особенно подготовленная трушта управления, являющаяся по- 
борником определенных уровней качества и тестирования. 


Понимание всеми участниками проекта необходимости тестирова- 
ния, подготовки версий, системного администрирования и других 
неярких, но имеющих большое значение работ (т.е. неприятие 
культуры “отдельных героев”) 


Реалистичные ожидания со стороны всех участников проекта, 
включая непосредственных исполнителей, менеджеров и заинте- 
ресованных лиц 


Стабильность проектной группы, отсутствие текучести персонала 


Выстроенные позитивные взаимоотношения в рамках проектной 
группы, включая непосредственных исполнителей, менеджеров и 
заинтересованных лиц 


и. Компетентная и своевременная поддержка тестовой среды 


Использование квалифицированных контрактников и консультани 
тов для заполнения вакансий 


Честность, обязательность, прозрачность, открытые планы, дос- 
тупные непосредственным исполнителям, менеджерам и заинтере- 
сованным лицам 


Наконец, несколько усложняющих факторов, которые всегдаувеличи- 
вают сроки и затраты: 


Большая сложность процесса, проекта, технологии, структуры 
компании или тестовой среды 


Большое число лиц, заинтересованных в тестировании, качестве 
системы или самом проекте й 


Внешние зависимости, особенно от незаинтересованных лиц 


Вопросы местоположения: географическое расположение проект- 
ных групп или помещений офисов, требующее частых поездок или 
увеличения времени на обеденный перерыв 


Большое количество подгрупп, особенно если они разделены гео- 
графически 


Необходимость поднимать, обучать и вводить в проект растущую 
группу тестирования или всего проекта 


Необходимость осваивать или разрабатывать новые инструменты, 
методы и технологии как в тестировании, так и в проекте в целом 


Наличие заказного аппаратного обеспечения 


Любое требование новой системы тестов, особенно для автомати- 
зированного тестирования, как часть работ по тестированию 
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є Любое требование разработки непротиворечивых тестовых сцена- 
риев с высокой степенью детализации, особенно в незнакомом 
стандарте документирования 


и Сложное расписание поступления компонентов, особенно для ком- 
_ плексного тестирования и разработки тестов 


ш Хрупкие тестовые данные, например чўвствительные ко времени 


Специфические аспекты проекта в каждой из категорий влияют на ре- 
сурсы и сроки, необходимые для выполнения определенных действий. 
При подготовке оценки затрат на тестирование тест-менеджер и те сотруд- 
ники группы тестирования, которые помогают ему провести оценку, долж- 
ны учитывать, насколько каждый из этих факторов влияет на оценку. 

Пренебрежение или пропуск одного из факторов может превратить 
реалистичную оценку в неверную и бесполезную. Опыт - это часто един- 
ственный учитель, но толковые тест-менеджеры могут научиться зада- 
вать умные вопросы и самим себе, и проектной группе о том, насколько 
каждый из факторов влияет на ход проекта. 


Представление реалистичной картины будущего проекта. 


Главное достоинство любого хорошего прогноза в том, что он сбывается. 
Предсказали ли мы будущее правильно с определенной степенью точно- 
сти? Конечно, будет какое-то отклонение, ошибка на какой-то процент 
времени и денег, но, если мы грамотно провели оценку, половина оценок 
будет завышенной, а половина заниженной. Также ошибка не должна 
превышать 10—20%, и ни в коем случае оценка не должна отличаться от 
фактического результата в несколько раз. | 

‚  К сожалению, многие официальные графики и бюджеты проектов 
превышаются, часто на значительные величины. Любой наудачу взятый 
экземпляр делового журнала или газеты, наверняка, содержит какую- 
нибудь “посмертную” историю о проекте в области информационных 
технологий или системной разработки, который вышел за рамки бюдже- 
та и сроков. По моему мнению, это происходит по нескольким причинам. 


ш Новые технологии. В некоторых случаях затраты в проектах, в кото- 
рых применяются новые технологии, недооцениваются. Никто ре- 
ально не знает, сколько времени нужно на выполнение работы, по- 
скольку никто никогда ее не делал. 


и Производительность рабочей группы. Некоторые проектные группы 
не достигают необходимого уровня эффективности или произво- 
дительности из-за текучести кадров, усталости основных исполни- 
телей, отсутствия обучения и т.п. (См. некоторые идеи о работе с 
этими проблемами в проекте в главах 8 и 9). 


и Отсутствие знаний. Некоторые группы управления проектом не 
способны применять подходящие методы оценки затрат. 


в. Отсутствие согласия. В некоторых проектах серьезные и непрерыв- 
ные споры между ключевыми заинтересованными лицами мешают 
достижению согласия относительно того, что же все-таки создает- 
ся. В результате мы не можем оценить затраты на тестирование в 
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постоянно меняющемся проекте, не может быть успешным выпол- 
нение всех работ проекта. 


ш Чрезмерные внешние ограничения. Некоторые группы управления про- 
ектом создают графики и бюджеты в рамках цифр, диктуемых мар- 
кетологами, пользователями и другими людьми, не участвующими 
в процессе разработки системы, ее сопровождения или поставки, 
что является дополнительной проблемой, если множество функ- 
ций системы и уровень ее качества также ограничиваются извне. 


ш Растянутые цели. Некоторые группы управления проектом объяв- 
ляют цели, которые, как им заранее известно, не будут достигнуты, 
для того чтобы увеличить давление на непосредственных исполни- 
телей и заставить их работать напряженнее. 


ш Финансирование. В некоторых случаях спонсирующие организации 
или кредиторы компании (например, вкладывающие свой капитал 
с риском) отказываются финансировать проект, если он стоит 
меньше, чем определенная сумма, или не выполняется по опреде- 
ленному графику, что сказывается на проектах с такими же объема- 
ми бюджетов и рубежами графика. 


За исключением первых двух факторов, это проблемы, с которыми мы 
можем и, я убежден, должны работать при подготовке оценки затрат. 
Я ставлю цель подготовить реалистичную, работающую и правдивую 
оценку затрат, а затем обсудить соответствующие изменения в рамках 
проекта и в тестовом покрытии как необходимые компоненты встраива- 
ния графика тестирования в общий график проекта. 

Реалистичность в подходе к оценке означает полноту. Другими слова- 
ми, Должны быть определены все задачи, необходимые для успеха проек- 
та. Я работал в большом проекте разработки, который был распределен 
по шести группам в трех городах на двух континентах. В начальный гра- 
фик проектная группа забыла включить фазы, действия и даже задачи ин- 
теграции компонентов и комплексного тестирования. Никаких ресурсов 
не было выделено на объединение составляющих систему компонентов, 
получаемых от различных групп, и на проверку этого объединения. 9:0 
нереалистично. 

Чтобы оценка была реалистичной, она должна учитывать каждую 
фазу, активность и задачу, необходимые для успеха. Строгое следование 
правилам декомпозиции работ, которые обсуждались ранее, — это один 
из способов обеспечить полноту включения всей проектной группы, осо- 
бенно опытных исполнителей, в процесс оценки затрат. 

Подготовка реалистичного графика также означает получение и ис- 
пользование разумных оценок затрат и ресурсов на каждую задачу. В дру- 
гом большом проекте одним из ключевых моментов был переход от хра- 
нилища плоских файлов к реляционной базе данных. На разработку 
инструментов и процесса для конвертирования всех данных из старой ар- 
хитектуры в новую было выделено всего две недели. Это тоже нереально. 

Для получения реалистичной оценки необходимо, чтобы она была ос- 
нована на разумной продолжительности задач. Здесь снова помогают сле- 
дование проверенным практикам составления декомпозиции работ, ме- 
тод экспертных оценок и другие методики, основанные на экспертизе 


внутри группы. 
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Назначение ответственных за выполнение 


Работающая оценка — это такая оценка, когда ответственные за все состав- 
ляющие задачи определены, согласны их выполнять и утверждены менед- 
жерами. Однажды я видел график, в котором декомпозиция работ была 
сделана только до уровня активностей, причем за каждую активность отве- 
чало до шести человек, а продолжительность составляла две-три недели. 
Как разобраться каждому из участников, что же ожидается от них? Чтобы 
дополнительно все запутать, группу тестирования назвали группой кон- 
троля качества. Они полагали, и им об этом говорили, что обязанность 
группы — внедрение изменений в процесс. Однако все остальные участни- 
ки проекта думали, что группа будет тестировать продукт. 

Я говорил куратору проекта из числа топ-менеджеров, что не пони- 
маю, как он будет определять, в каком месте графика он находится, те ли 
задачи выполняют участники проекта. С работающей оценкой все пони- 
мают, какие задачи попадают в их сферу ответственности и как можно 
оценить степень завершенности каждой из задач в терминах передавае- 
мых результатов. 

Работающие оценки также учитывают ограничения привлекаемых ре- 
сурсов. Например, классической ошибкой является планирование ис- 
пользования одного серверного кластера как для функционального, так 
и для нагрузочного тестирования в одно и то же время. Другая проблема 
возникает, когда планируют использование тестовых сред, расположен- 
ных в других офисах, не имея практической возможности контролиро- 
вать конфигурирование и работу этих сред. Существуют зависимости ме- 
жду задачами тестирования, связанные с используемыми ими ресурсами. 

Работающая оценка должна выявлять не только зависимости между ре- 
сурсами, но и все другие зависимости, взаимосвязанные цепочки задач 
и критические пути. Необходимо понимать, что оценки затрат не достиг- 
нут совершенства. Следовательно, необходимо пытаться предсказывать 
последствия позднего завершения задачи или ее выхода из бюджета. Это 
особенно важно для тест-менеджера, который должен понимать, когда, 
кем и в результате какого процесса каждый из передаваемых результатов 
будет предоставлен его группе. 

Зависимости, взаимосвязанные цепочки и критические пути также 
являются элементами правдивых графиков. Сочетание рисков вдоль 
критического пути —удивительный, но важный факт для осознания тес- 
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тировщиками и менеджерами. Посмотрим на сочетание рисков с мате- 
матической точки зрения. 

Пусть имеется 12 задач на критическом пути в проекте. Вероятность 
завершения в срок любой из задач равна 90%. Вероятность завершения 
раньше срока любой из задач равна 0%. Заметим, что своевременное за- 
вершение каждой задачи зависит от своевременного завершения преды- 
дущих задач. Статистическое представление, носящее название теоремы 
Байеса, имеющей дело сусловной вероятностью, говорит о том, что веро- 
ятность завершения в срок последней задачи в перечне меньше 30%: 


0.9х0.9х 0.9х0.9х 0.9х0.9х 0.9 х 0.9 х0.9х 0.9 х0.9х0.9 = 0.912 0.98 


Если вероятность завершения каждой из задач снизить до 75%, сум- 
марные шансы своевременного завершения всех задач падают до 3%. 
А что если, как часто это бывает, последняя задача на критическом пути — 
это рубеж, означающий завершение проекта? Сочетание рисков на кри- 
тическом пути дает нам лишенное эмоций логическое, чисто математиче- 
ское объяснение, почему использование графиков как растянутых целей 
или как средства принуждения людей работать напряженнее, является 
столь непродуктивным и часто безуспешным. 

Планы на случай непредвиденных обстоятельств, резерв времени, 
контрольные точки и критерии начала фаз могут способствовать разре- 
шению проблем графика, связанных взаимозависимостями задач. Гра- 
мотные оценки учитывают проблемы в выполнении задач в ограничен- 
ные периоды времени. Они позволяют реагировать и регулярно 
пересматривать график. Они позволяют увидеть нарушение сроков и за- 
трат, связанных с задачами критического пути или близкими к нему, 
иуправлять ими до того, как в конце проекта разразится кризис графика. 


Честные прогнозы 


Правдивые оценки предполагают полное доверие группе. Когда менедже- 
ры запрашивают оценки затрат у сотрудников своих групп, они должны 
воспринимать полученные оценки как реалистичные, а не как коварные 
попытки лентяев получить удобный график. Вспоминаю совещание, на 
котором менеджеры проектов признали, что действующий график явля- 
ется фикцией, но согласились оставить его без изменений, чтобы устано- 
вить растянутые цели для группы разработки. 

Такой стиль руководства производит на меня впечатление нечестного 
и основанного на предположении, что люди ленивы от природы. На са- 
мом деле большинство оценок затрат, которые я получаю от своих со- 
трудников, обычно слишком оптимистичны. Мне приходится обсуждать 
эти оценки с людьми и обычно изменять их в сторонуувеличения. Иногда 
исполнители не видят других “изменяющихся к. которые оказыва- 
ют влияние на их производительность. 

Мы должны быть честными и правдивыми также в наших собственных 
суждениях, особенно имея дело с тем, что мы пока не знаем. В “Апологии 
Сократа” Платон цитирует философа, который предполагает, что знание 
собственного уровня незнания есть сущность человеческой мудрости. 
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Я встречал оценки, которые в два раза отличались от реальных затрат. Но 
я не помню случая, чтобы какие-либо из них были недостаточными. 

Существует предел знаний о ходе проекта в первые несколько недель. 
Снова отмечу, что резерв времени, планы на случай непредвиденных об- 
стоятельств, контрольные точки и критерии начала и завершения фаз по- 
зволяют снизить риск неточных оценок и своевременно отреагировать 
на расхождения действительности и оценок. Когда мы видим, что это 
происходит, честность требует смело говорить об этом вслух. При чест- 
ной оценке затрат все менеджеры и непосредственные исполнители не 
боятся указывать группе управления проектом на расхождения в случае 
их возникновения. 

Наконец, подготовка реалистичных, работающих и правдивых оценок 
затрат также требует, чтобы мы согласились с контекстом и ограничения- 
ми проекта. Если я представлю руководству график и бюджет подпроекта 
тестирования, который сдвигает дату выпуска на 50% и превышает бюджет 
на 200%, с моей стороны нереально ожидать утверждения менеджментом 
таких оценок. Да, это верно, что тестирование обычно увеличивает про- 
должительность проектов. Часто действительно необходимо заложить 
больше тестирования, но это не означает непреклонного отказа работать 
в разумных рамках. 

Я извел море чернил на эти три главы, посвященные оценке затрат, 
поэтому вы, вероятно, поняли, что я очень беспокоюсь об этом. Почему 
оценка затрат так важна? Я участвовал в нескольких проектах, в которых 
оценка была выполнена хорошо, и работать в этих проектах было истин- 
ным наслаждением. Проектные группы сверху донизу ощущали гордость, 
когда своевременно достигались рубежи и проект успешно завершался. 
Ключевые заинтересованные лица, не входящие в проектную группу, 
были рады получить системы в срок и в рамках бюджета. Я также работал 
в проектах, в которых, надо честно признать, напряженно работающих 
программистов, тестировщиков и других непосредственных исполните- 
лей уговаривали, ругали и обвиняли в результатах неудачных оценок за- 
трат, сделанных руководством. В двух таких проектах неудачные оценки 
проявлялись как раз в конце проекта, в ходе тестирования, заставляя 
меня бороться за то, чтобы сделать что-то полезное, в то время как другие 
менеджеры тайно ворчали, рассуждая, сколько еще продлится тестирова- 
ние. Неверная оценка затрат обрекает проект и проектную группу на не- 
удачу. 

Таким образом, я думаю, что мы, специалисты по разработке программ- 
ного обеспечения, должны начать настраивать себя на успех. Успех проек- 
та опирается на баланс свойств, сроков, бюджета и качества. Реалистич- 
ные, работающие и правдивые оценки затрат непосредственно в начале 
проекте — важная часть построения этого баланса. Если имеются честные 
оценки графика проекта и мы честны с нашими руководителями, коллега- 
ми, группами и самими собой при обсуждении оценок, это настраивает нас 
на успех. Если нам известно, кто, что и ккакому сроку должен сделать и ка- 
кие существуют зависимости и риски, это также настраивает нас на успех. 
Подготовка оценки с учетом всех взаимозависимостей — это не скучная ру- 
тинная бумажная работа, с трудом выполненная во второй половине дня 
в Мсгозой Ргоуесе и затем забытая. Оценка затрат — это важнейшая функ- 


Глава 5. От оценки затрат к базовой версии 137 


ция управления, направленная на получение одобрения заинтересован- 
ных лиц, определение реалистичных ожиданий, честное обсуждение с со- 
трудниками возможных достижений и управление успехом проекта. 


Быстрая оценка затрат 


Оценка затрат полезна, поскольку является прогнозом. Оценка затрат 
позволяет нам предсказать будущее и соответствующим образом стро- 
ить планы. Оценка проекта тестирования — график, бюджет, окупае- 
мость инвестиций — это прогнозы на будущее в терминах сроков и фи- 
нансовых затрат. | 

Как и все оценки, ваша оценка будет неточной и до некоторой степени 
неверной. Это нормально. Вы можете прекрасно предсказать погоду на 
завтра, если подождать до послезавтра. Но ценность предсказания в том, 
что вы заглядываете в будущее и получаете возможность предпринять 
своевременные действия, чтобы повлиять на это будущее. 

Как при управлении морским судном, чем раньше вы начинаете дейст- 
вовать, тем менее усердными и исключительными должны быть ваши уси- 
лия. Если вы начинаете слишком поздно, никакие корректирующие дей- 
ствия вам не помогут. (Продолжая морскую тему, можно вспомнить, что 
попытка вырулить “Титаник” от судьбоносного айсберга началась слиш- 
ком поздно.) Таким образом, значение любой оценки состоит в том, что- 
бы она была в наличии, когда требуется принимать меры, а также в том, 
что реализация плана, вытекающего из оценки затрат, добавляет стои- 
мость описанными выше способами. | 


Решение проблем 


В рассматриваемом нами конкретном случае приведен пример того, что 
происходит, если процесс оценки был успешным. К сожалению, этот про- 
цесс не всегда идет гладко. Предусмотрительные тестировщики готовят- 
ся к проблемам, которые порождают оценки затрат. | 


Тестирование как объект инвестиции 


При обсуждении окупаемости инвестиций в тестирование я упростил 
картину за счет вычисления затрат и доходов, как будто они имеют место 
примерно в один и тот же период времени. Очевидно, что затраты на тес- 
тирование распределяются по всему графику проекта. Это также верно 
для информации, которая направляет проект, поскольку значение этой 
информации осознается в ходе проекта. 

Тем не менее стоимость, добавленная за счет обнаружения дефектов 
(независимо от их устранения) и за счет снижения рисков, относящихся к 
ошибкам, которые могли быть внесены, накапливается в течение некото- 
рого периода времени после завершения проекта. Это приводит к двум 
оговоркам, касающимся подхода к окупаемости вложений, которые нуж- 
но иметь в виду, если метод применяется с целью обоснования предлагае- 
мого бюджета. 
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Во-первых, многие проекты используют учетную политику и стимули- 
рованиє, работающие против окупаемости вложений в тестирование. 
В большинстве случаев проекты имеют установочный бюджет, включаю- 
щий в себя только затраты, связанные с выпуском текущей версии. Затра- 
ты, понесенные за счет неверных решений, принятых в ходе проекта, 
и проявившиеся при сопровождении, не берутся в расчет бюджета проек- 
та так же, как и полученные доходы, которые проявляются позднее. Та- 
ким образом, группа управления проектом, как это ни печально, имеет 
стимулы находить и исправлять только те ошибки, которые никак нельзя 
оставить в продукте для его выпуска. 

Вновь обратимся к гипотетической модели стоимости качества (см. 
главу 4), воспроизведенную для удобства на рис. 5.1. Предположим навре- 
мя, что мы живем внутри комикса про Дилберта, и допустим, что проект- 
ная группа должна исправить только половину из 1000 ошибок, имеющих- 
ся в системе, чтобы продукт нормально работал перед поставкой. Это 
даст на основе модели 10%-ный средний рейтинг удовлетворенности 
пользователя. | 

(Дилберт - известный в США рисованный персонаж, созданный худож- 
ником Скоттом Адамсом. Дилберт — самый известный офисный работник 
в США, постоянно попадающий в различные забавные ситуации вместе со 
своим лысым боссом. Пример комикса с русским переводом можно найти 
на һр: / /обгог.сопіліа / паці / плізс / 2001-05-24-7.5піті. — Прим. пер.) 

Предположим, что менеджер проекта достаточно циничен, чтобы 
считать, что все ошибки, обнаруженные после выпуска версии являются 
проблемами менеджера службы технической поддержки. Допустим, что 
ежемесячно обнаруживается половина из оставшихся ошибок, и, таким 
образом, доля обнаруженных дефектов уменьшается до ничтожно малой 
величины примерно через шесть месяцев после выпуска версии. Сейчас 
модель показывает затраты на несоответствие примерно $550 000 при 
удовлетворенности пользователя в 10%. На рис. 5.2 показаны затраты на 
несоответствие, сходящиеся кэтому числу в первые шесть месяцев. Более 
того, заметим, что до выпуска версии окупаемость инвестиций в тестиро- 
вание на самом деле отрицательная, поскольку затраты на соответствие 
превосходят затраты на несоответствие. | 

Хорошо, покинем комикс Дилберта — он слишком мрачный. Предпо- 
ложим, что есть менеджер проекта, заботящийся о пользователях. Он 
нанимает независимого тестировщика для обнаружения большинства де- 
фектов до поставки версии. Он также определяет цель для разработчи- 
ков; устранить две трети ошибок до выпуска версии, примерно на 
150 ошибок больше, чем в предыдущем варианте. На рис. 5.3 показано, 
как работает этот подход в начальный период эксплуатации версии. 
В перспективе стоимость качества снизится примерно до $200 000, что со- 
ставляет треть величины, полученной в предыдущем примере (рис. 5.2). 
Это существенный прогресс. 

Однако в ближайшей перспективе, которую видят те, кто ведет учет 
затрат проекта, — это более дорогой проект. Для менеджеров проекта, 
которые получают премии от прибыли проекта, а не от долгосрочной 
прибыли, получаемой от разработки системы в течение всего ее жиз- 
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ненного цикла, затраты на тестирование всегда будут неизбежной по- 
мехой . 

Во-вторых, поскольку некоторая экономия затрат на несоответствия 
проявляется со временем, продолжительность этого времени может 
уменьшить окупаемость вложений в тестирование. В бухгалтерском учете 
это понятие носит название “чисто приведенная денежная стоимость” (пе 
ргезепі уаїце ої топеу). Чисто приведенная денежная стоимость говорит 
о том, что $1000 через шесть месяцев будут стоить меньше чем $1000 сего- 
дня, поскольку мы можем вложить $1000 сегодня и получить болыше чем 
$1000 через шесть месяцев. Насколько больше? Это зависит от процента 
окупаемости альтернативных вложений. 

Вернемся к основному примеру книги, чтобы проиллюстрировать 
этот тезис. Для каждой исправленной ошибки, найденной группой Джа- 
мала, анализ окупаемости вложений, сделанный им, предполагает воз- 
врат около $1100. Вто же время экономия в $1100 не имеет места одновре- 
менно с выпуском версии системы. Она происходит в некоторый момент 
в будущем, когда некоторое число пользователей встретят эту ошибку 
и потребуют ее исправить. Поскольку нам неизвестно точно ни для одной 
ранее исправленной ошибки, когда она могла бы проявиться, так как бо- 
лее некому объявить о ее отсутствии, момент, в который будет зафикси- 
рована экономия, неизвестен и не может быть выявлен в принципе. Од- 
нако мы можем посмотреть на итоговые результаты. | 

В главе 4 было отмечено, что поддержка версии “Суматра” завершает- 
ся по прошествии одного года после ее выпуска. Предположим, что ме- 
неджер поддержки Косимо Неграев говорит Джамалу, что в каждый ме- 
сяц первого года он получает сообщения о половине ошибок, ранее не 
обнаруженных в версии. Если Джамал принимает альтернативный про- 
цент окупаемости вложений как 18% в год, или 1.5% в месяц, он может 
проанализировать вторую черновую версию бюджета и подсчитать воз- 
врат вложений на основе чисто приведенной стоимости, как это показа- 
но на рис. 5.4. (Заметим, что цифры, показанные на рисунке, учитывают 
два направления экономии затрат, согласованные Джамалом с Гарольдом 
и Джоном в основном примере книги.) 

Сейчас возврат инвестиций в тестирование, равный 420%, не делает 
хуже бизнес-план Джамала. Но являются ли 18% в год разумной альтерна- 
тивой вложений? 

Более вероятно, что вся сумма или часть ее, которую запрашивает 
Джамал, может быть израсходована на наем новых программистов для 
реализации дополнительных свойств или ускорения сроков выполнения 
проекта. Каков процент окупаемости вложений при различных альтерна- 
тивах, существующих в диапазоне от 0 до 40% средств (как предлагает 
Джамал), выделяемых на тестирование? | 


1 Согласно гипотетической модели устранение примерно 900 ошибок минимизировало 


бы стоимость качества. Модель дает эту цифруна основе затрат на соответствие и затрат на 
несоответствие (при различных уровнях удовлетворенности пользователя) и соотношения 
между дефектами в поставленной версии и удовлетворенностью пользователя. В реально- 
сти лишь немногие менеджеры проектов имеют под рукой эту информацию, что делает вы- 
бор оптимального объема тестирования и исправления дефектов трудным даже для настоя- 
щих сторонников возврата стоимости качества. 
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Я поднимаю эти вопросы не для того, чтобы отговорить читателя от 
проведения анализа окупаемости вложений в тестирование. Для 
тестировщиков-профессионалов, особенно тест-менеджеров, важно по- 
нимать финансовые последствия того, что они делают. Тем не менее 
при подсчете окупаемости вложений в тестирование я помню об ограни- 
чениях, присущих этим расчетам. Модели являются интуитивными на 
высоком уровне абстракции, но некоторые детали по-прежнему остают- 
ся проблемами. Эти проблемы могут вызвать недоверие к полученным 
цифрам, а также породить различные политические вопросы. В некото- 
рых случаях лучше отказаться от подсчета окупаемости инвестиций 
в тестирование. 


Возможно, это похоже на чудо, но это только оценка 


Поскольку окупаемость инвестиций вычисляется приближенно, это 
только оценка. (Это то же самое, что и прогноз погоды или другое пред- 
сказание.) Продемонстрированный процесс оценки затрат, несмотря 
на все доверие кцифрам и данным, не является точной наукой. Мы смот- 
рим на предыдущие проекты. Мы изучаем некоторые цифры. Мы мани- 
пулируем этими цифрами различными способами. Мы обсуждаем с дру- 
гими людьми сделанные допущения. Из этого процесса возникают 
несколько документов, которые, возможно, предсказывают будущее. Со- 
всем не волшебным образом мы можем предсказать, что солнце скрыва- 
ется за горизонтом каждую ночь. Тем не менее есть что-то чудесное 
в том, что мы можем предвидеть итог такого сложного и уникального 
предприятия, как разработка, сопровождение или поставка системы 
хотя бы с некоторой точностью. 

Я помню, как был очарован моими ранними оценками затрат в проек- 
тах. Я согласен, что часто не останавливался ни перед чем, чтобы поста- 
раться сохранить мои оценки точными, подгоняя проект под мои оценки 
иногда довольно бессмысленным образом. Если я утверждаю в графике, 
что задача займет пять дней, а это на самом деле не так, разумно ли гово- 
рить о том, что задача завершается через пять дней? Не нужно ли еще по- 
учиться оценке затрат, если очевидно, что оценка неверна, и требуется 
вновь анализировать ситуацию? 

Признание ошибок и извлечение из них уроков всегда лучше в долго- 
срочной перспективе, но делать это — не является сущностью человече- 
ской природы. Часто более естественно обвинить кого-либо другого. Мы 
можем думать, что оценка была верной, но группа все испортила и делала 
дольше, чем, согласно оценке, должна была делать. 

При разумном управлении мы должны пересматривать оценки, а не 
продолжать следовать ошибкам, вводя в заблуждение и обвиняя всех 
и вся. Если согласно карте вы должны ехать сквозь дерево, а не объезжать 


1 Например, Джоанна Ротман (Јоһаппа Коштап) в ходе переписки со мной указала, что 
цифрами окупаемости вложений в тестирование легко манипулировать. Более того, анализ 
окупаемости вложений может привести к тому, что будут проигнорированы важные риски, 
как отмечает Сем Канер (Сет Капег) в статье “Ола Созі Апа[уз15 Вепебіз апа Кізк5" на 
мии’. Капег.сот. 
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его, вы жене будете настаивать на точности карты и не попытаетесь про- 
бить машиной дерево? 

Есть предел волшебства в оценке затрат. Если вы з й о получе- 
нии хороших оценок, у вас в значительной степени больше шансов на 
это, нежели в случае, если вы берете цифры с потолка или колдуете над 
трафиками Гантта и таблицами, не имеющими ничего общего с реально- 
стью, но сообщаете старшим менеджерам информацию, которую они хо- 
тят услышать. Тем не менее процесс оценки затрат в проектах разработ- 
ки, сопровождения или поставки систем полон потенциальных ошибок. 
Кажущиеся незначительными ошибки при составлении декомпозиции 
работ могут привести к серьезным неточностям в конечных оценках. По- 
жалуйста, не поймите меня неправильно: я делаю оценки затрат и делаю 
это тщательно. Если я не отношусь к оценке затрат тщательно, то я не 
управляю процессом и, следовательно, рискую. Но я научился не видеть 
волшебства в предвидении там, где есть только очень искусно выстроен- 
ная и тщательно и многократно перепроверенная приблизительная 
оценка. 


"Правило девяти месяцев 


Хорошо известный афоризм управления гласит, что неважно, сколько 
пар участвует в процессе, потребуется, как минимум, девять месяцев 
плюс-минус несколько недель, чтобы родить ребенка. Другими словами, 
есть определенные задачи, имеющие определенную присущую им мини- 
мальную продолжительность независимо от числа людей, ответственных 
за их выполнение. Пренебрежение этим афоризмом — одна из классиче- 
ских ошибок при оценке затрат. 

Одна из ловушек связана. с тем, что Фред Брукс назвал мифическим 
человеко-месяцем. Некоторые при оценке проектов по созданию систем 
подсчитывают общее число необходимых человеко-месяцев, а затем счи- 
тают, что могут произвольно сократить сроки проекта, добавив нужное 
количество людей. Брукс указал, что это миф, поскольку само добавление 
дополнительного числа людей может увеличить общее число человеко- 
месяцев, необходимых для выполнения проекта. Вот сформулированный 
по-другому знаменитый закон Брукса: “Если проект неукладывается в сро- 
ки, то добавление рабочей силы задержит его еще больше”. Меньшее чис- 
ло людей могут работать более эффективно, а накладные расходы, свя- 
занные с координацией работ большего числа людей, перекроют все 
преимущества. 

В некоторых случаях тестирования закон Брукса не работает. Напри- 
мер, в случае, если имеются скрипты для ручного тестирования, обычно 
можно использовать младших тестировщиков, потратив не более недели 
на их обучение и ввод в Проею и поделить работу непосредственно на 


Книга Брукса “Мифический человекомесяц" остается прекрасным исследованием тонко- 
стей управления системными проектами. Впервые она была опубликована в 1975 г., 
ав 1995 г. вышло исправленное и дополненное издание. Мерилом общности и неисгребимо- 
сти проблем, возникающих перед группами разработки систем, является то, что книга по- 
прежнему остается актуальной, а новое издание было только дополнено и практически не 
изменилось. 
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уровне тестовых сценариев. Однако разработка тестовых данных, конфи- 
гурирование тестовой среды, написание тестовых сценариев, разработка 
автоматизированных тестовых скриптов или инструментов тестирова- 
ния так же сложны для решения, как и программирование, и подчиняют- 
ся закону Брукса. 

Еще одна ловушка возникает из-за нереалистичного планирования 
на проектном уровне. Обычно тестировщикам довольно трудно по- 
нять это без достаточного опыта в программировании. Тем не менее 
можно поискать некоторые признаки того, что вас пытаются ввести 
в заблуждение. 

Одним из таких признаков является декомпозиция работ проекта, не 
соответствующая критериям, определенным в главе 8. Пока остаются уча- 
стники проекта, которые могут неверно понять свои задачи в проекте, 
график остается похожим на сочинительство. 

Другим признаком является информация о том, что процесс составле- 
ния графика ведется от произвольной даты поставки продукта. Еще хуже, 
если люди понимают, что для выполнения проекта в указанный срок не- 
обходимо существенное улучшение процессов, т.е. они просто полагают, 
что улучшение процессов произойдет само собой без приложения сил 
в этом направлении. | 

Если имеются подозрения насчет упущений в графике, нужно особен- 
но тщательно определять связь задач и критерии начала фаз тестирова- 
ния. В противном случае проблемы графика незаметно проникнут в тес- 
тирование и вас посчитают ответственным за них. (Более подробно эти 
вопросы рассматриваются в главах 6 и 7 при обсуждении вопросов плани- 
рования.) Более того, насколько ни были бы важны при оценке затрат 
планы на случай непредвиденных обстоятельств и резервы времени, они 
имеют еще большее значение при оценке подпроекта тестирования, ко- 
торый существует в рамках неадекватного графика или дефицитного 
бюджета для всего проекта разработки системы. 


Осторожно! Незаинтересованные лица! 


Быть честным перед самим собой означает быть честным относительно 
рамок подпроекта тестирования в объемлющем проекте и относительно 
того, как другие люди видят проект, в котором я участвую. Подпроект тес- 
тирования обычно прочными нитями связан с тем, что происходит с про- 
ектом вне тестирования. Обычно это связи с другими участниками про- 
ектной группы. Эти люди непосредственно заинтересованы в успехе 
проекта. Поэтому, хотя нужно тщательно управлять взаимосвязями с ло- 
гической точки зрения, по всей видимости, у вас не будет проблем в моти- 
вации взаимодействия. Как заметил однажды один толковый менеджер: 
“Пока мы все в одной лодке, не вижу большого смысла выбрасывать на 
скалы нос или корму”. 

Однако иногда мы зависимы от людей, не вовлеченных в проект или, 
возможно, даже враждебных ему. Это мощный фактор, влияющий на 
оценку затрат на тестирование. 

В одном из проектов моя группа тестирования имела три таких зависи- 
мости, которые оказались исключительно проблемными. Во-первых, 


Глава 5. От оценки затрат к базовой версии 147 


была группа системного администрирования, которая не сделала своим 
приоритетом настройку тестовой лаборатории. Они работали над многи- 
ми другими проектами. Им казалось, что наш проект будет отменен. Они 
просто не хотели связываться с настройкой десятка тестовых рабочих 
станций с одинаковыми конфигурациями, которые ноделировали кон- 
фигурации развернутой системы. 

Во-вторых, была группа, отвечавшая за администрирование сущест- 
вующей системы, для которой мы готовили замену. Нам нужен был доступ 
к той системе в качестве эталонной платформы или тестового оракула для 
определения корректности результатов работы системы, предназначен- 
ной для тестирования. (Тестовый оракул подробно рассматривается 
в главах 10 и 11.) Однако поскольку операторы существующей системы ос- 
тавались без работы в случае успешного завершения проекта, в лучшем 
случае они оказывали нам помощь с выражением ‘неприязни. 

Наконец, группа информационных систем, занимавшаяся поставкой 
программных продуктов, для которых эта (большая) компания имела ли- 
цензии, не считала, что нам нужны десятки лицензий для системы отсле- 
живания дефектов. Эта проблема особенно обострилась, когда мы попро- 
сили настроить двух удаленных клиентов’ для компании, которая 
разрабатывала большую часть кода. 

Ни одна из задач, которую должны были выполнить для нас эти неза- 
интересованные стороны, не заняла бы больше чем один рабочий день 
тестировщика, включая разъяснение необходимости, помощь в обеспе- 
чении соответствующего доступа и проверку завершения задачи после 
выполнения тестов. На деле группа тестирования потеряла, по крайней 
мере, три человеко-недели, пытаясь разобраться с кумулятивным эффек- 
том задержек и пассивного сопротивления. Все время между планирова- 
нием и выполнением тестов занимало решение этих проблем. Проблемы 
были бы несерьезными, если бы люди в других группах, от которых мы за- 
висели, просто выполняли свои обязанности. Поскольку они не были за- 
интересованными лицами проекта, у них отсутствовали стимулы делать 
это. Такое поведение незаинтересованных лиц имело исключительно 
разрушительные последствия для подпроекта тестирования и проекта 
в целом. 

Рассмотренный пример демонстрирует, что может произойти в том 
случае, когда имеются зависимости вне проекта. Определение контекста 
проекта очень важно, поскольку позволяет рассмотреть тех, кто способ- 
ствует выполнению проекта и проведению в нем тестирования, а кто — 
нет. Если я вижу, что возможны задержки со стороны незаинтересован- 
ных лиц, я ограничиваю зависимость от тех людей, чьи интересы не соот- 
ветствуют успешному выполнению проекта, до возможного минимума, 
лучше всего до нуля. Если по какой-либо причине я не могу этого сделать, 
то прилагаю усилия, чтобы задачи с такими зависимостями не попадали 
на критический путь, и предупреждаю руководство о том, что я ожидаю 
возникновения проблем. 

Для любых задач с такими зависимостями я создаю приличный резерв 
времени. Я также рассчитываю на то, что придется предпринять значи- 
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тельные усилия для выполнения моей части этих и всех зависимых задач. 
Наконец, я получаю солидный однозначно сформулированный документ 
с обязательством участников и менеджеров выполнить все зависящее 
внутри проекта и с определением быстрого способа эскалации проблем 
на необходимый уровень руководства. В следующих двух главах по плани- 
рованию тестирования будет показано, как я это делаю. 


Когда “продают” неудачные оценки 


Предположим, что мы завершили процесс оценки затрат, включаю- 
щий в себя создание бизнес-плана и определение реалистичной оцен- 
ки, и получили заключение: “Мы не можем себе это позволить, и у нас 
нет столько времени. Вот сколько у вас есть денег, вот вероятные сро- 
ки; теперь идите и тестируйте систему”. Что теперь? Здесь я бы попы- 
тался найти разумный компромисс между глубиной и широтой покры- 
тия. В качестве вспомогательного средства я бы взял результаты 
анализа риска качества. : 

Если группа управления проектом предлагает пойти на риски, кото- 
рые мне кажутся неразумными, я стараюсь объяснить свою позицию. Ко- 
гда я это делаю, то имею в виду, что предприниматели и технологи, как 
правило, больше привержены риску, чем тестировщики. Обычно мне от- 
вечают примерно так: “Да, Рекс, мне понятно твое мнение, но я не соби- 
раюсь тратить больше денег и откладывать сроки, чтобы снизить эти рис- 
ки”. Если по какой-либо причине я прекращаю тестирование раньше, чем 
должен, то тщательно документирую риски, которые остались непокры- 
тыми тестами. 

Стремление к компромиссу по поводу объема тестирования и доста- 
точного бюджета и графика для поддержки такого тестирования — не то 
же самое, что отказ от своих оценок. Другими словами, если я защищаю 
реалистичный бюджет и оценку затрат, руководство может либо поддер- 
жать эту оценку, либо урезать рамки тестирования и попросить меня со- 
гласиться с меньшим бюджетом и более короткими сроками. Но иногда. 
вместо этого меня просят сделать то, о чем ранее я говорил так: “Возьми- 
те Х долларов и У месяцев за две трети стоимости в половину времени и 
посмотрите, что получится”. Тим Коомен указал мне при рецензирова- 
нии предыдущей главы: “На совещании [посвященном обсуждению оце- 
нок] никогда не соглашайся безвозмездно убрать часы, например: “Мы бу- 
дем работать немного напряженнее и, я думаю, сможем завершить все 
в указанный вами срок”,- поскольку в этом случае ты теряешь доверие”. 
Я искренне согласен с его утверждением. 

Наконец, может оказаться отдельной трудной задачей убедить руково- 
дство в реалистичности оценок, если у него уже имеется опыт работы 
с фиктивными оценками других менеджеров или предшественников в от- 
деле тестирования. Если предыдущий тест-менеджер, скажем, брал циф- 


‚ры с потолка, а затем не мог достичь поставленных целей по срокам 


и бюджету, руководство могло придти к мнению, что ни один тест-менед- 
жер насамом деле не знает, как проводить оценку затрат. Я работал В ком- 
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паниях, в которых вся группа технических менеджеров обвинялась 
в этом. Справедливо или нет, но если вы начинаете в условиях дефицита 
доверия к оценкам, необходимо преодолеть эти обстоятельства. Как го- 
ворится в старой пословице, если вы оказались в яме, первым делом нуж- 
но прекратить копать ее дальше. В этой ситуации нужно особенно тща- 
тельно готовить только наилучшие, наиболее аккуратные оценки, но вы 
же всегда так делаете, верно? Я 


Системы с повышенными требованиями к безопасности 
или к выполняемой целевой задаче 


Конечно, положительное сальдо окупаемости инвестиций само по себе 
неплохо, однако в жизни не все решают деньги. В некоторых случаях сис- 
темы, которые мы разрабатываем, имеют большое значение для безопас- 
ности людей или выживания бизнеса, что выходит за пределы возможно- 
стей любых финансовых моделей оценки. 

Одна из сильных сторон формального анализа рисков качества, в ча- 
стности метода анализа видов ошибок и их влияния, состоит в том, что 
он отличается выявлением действительно ключевых рисков качества и 
соответствующих видов ошибок для систем, от которых зависит жизнь 
человека или непрерывное функционирование бизнеса. Если вы рабо- 
таете в такой среде, необходимо тщательно следить за тем, чтобы не по- 
терять достижения анализа рисков качества в ходе оценки затрат, со- 
ставления графика и планирования бюджета. Перед обсуждением 
активности, задачи или ресурса еще раз нужно проверить, что при ис- 
следовании этих критических типов рисков необходимо учитывать не 
только затраты. Если вы уверены, что сокращение тестирования выль- 
ется в дополнительный риск для человеческой жизни, ваша моральная, 
юридическая и профессиональная обязанность — предпринять реши- 
тельные меры. 

Я бы порекомендовал для начала опробовать все возможные способы 
для разрешения проблем, эскалируя их на разные уровни руководства 
компании. Вы подвергнете опасности весь свой политический капитал, 
если не будете использовать его тонко и осторожно. Важно также пони- 
мать, что вы можете ошибаться. На самом деле, все участники проекта мо- 
гут до некоторой степени заблуждаться в своем понимании рисков. Вы, 
возможно, особенно опасаетесь рисков, в то время как другие не столь ос- 
торожны. Открытость к компромиссам и склонность поступаться прин- 
ципами — это две разные вещи. Для эффективного взаимодействия необ- 
ходимо слушать и понимать, что говорят другие, а также уметь объяснить 
свою позицию. 

Если вы чувствуете, что риски непреодолимы, а другие не разделяют 
вашу озабоченность, вероятно, вы не донесли свою точку зрению надле- 
жащим образом. (В главе 15 рассматривается трагический пример не- 
удачного взаимодействия при выполнении полета американского кос- 
мического челнока “Челленджер” в 1986 г.) Люди могут понимать 
и принимать вашу озабоченность, однако это не значит, что они понима- 
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ют, почему вы озабочены. Если вы чувствуете, что остаются риски, угро- 
жающие жизни, ваша обязанность — донести проблему с помощью 
данных в не оставляющей вопросов форме людям, которые могут при- 
нимать решения. 

Если вы исчерпали способы разрешить проблему обычными путями, 
что дальше? Возможно, у вас есть право сообщить об определенных дей- 
ствиях, которые могут угрожать жизни или общественной безопасно- 
сти. Вероятно, вас заставит действовать ваша совесть. Тем не менее вы- 
ступать в качестве доносчика — не самый легкий выбор. Рекомендую 
в этом случае перед принятием решения в спокойной обстановке посо- 
ветоваться с надежными друзьями, семьей или взять юридическую кон- 
сультацию. 


Внедрение усовершенствований 


Научиться создавать реалистичные, точные, правдивые оценки затрат 
и убеждать руководство поверить в них, а также управлять подчиненнь- 
ми и взаимодействовать с коллегами было, вероятно, наиболее трудным 
для меня при переходе от непосредственного исполнителя к роли тест- 
менеджера. Люди стремились к предвидению с давних времен, мифоло- 
гия полна рассказов о тех, кто умел предсказывать будущее. Я не претен- 
дую на то, чтобы достичь возможностей Пифии, главной жрицы Дельф, 
но я бы порекомендовал следующие шаги для улучшения методов оценки 
затрат. 


1. Изучите тему оценки затрат. Это важно для тех из нас, кто дол- 
жен проводить оценку затрат на тестирование систем, для того, 
чтобы иметь основные инструменты под рукой. Следовательно, 
важно научиться составлять хорошо организованную декомпози- 
цию работ. Также важно понимание, как соединить бюджет 
и бизнес-план. Поскольку бизнес-план тестирования основан 
в значительной степени на стоимости качества, изучение этой 
темы также важно. Вероятно, вы обнаружите, что по мере изуче- 
ния этих тем вы станете не только более компетентным как тес- 
тировщик, но и заслужите больше доверия. Учитесь говорить на 
языке менеджеров проектов. Вырабатывайте навыки, необходи- 
мые для представления и защиты проекта тестирования понят- 
ными им словами. Учитесь обсуждать предложения по урезанию 
бюджетов тестирования иначе, чем просто утверждать: “Вы бы 
не предложили этого, если бы беспокоились о качестве”. Нужно 
уметь говорить о конкретных рисках, затратах и альтернативах, 
а также вносить контрпредложения, которые позволяют достиг- 
нуть взаимного удовлетворения и поддержки руководства без оз- 
лобления сторон. | 


2. Учитесь на прошлых проектах, на нынешних проектах и у других 
людей. Основные методы оценки затрат на тестирование — это 
пустые сосуды, которые вы можете и должны заполнить данными. 
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Посмотрите на предыдущие проекты и замените гипотетические 
данные в таблицах и декомпозиции работ, которые приводятся 
в этой книге, данными из вашего опыта. Сбор данных из текущего 
и будущих проектов поможет оценкам в будущем. Отслеживайте 
текущие проекты и сравнивайте фактические результаты с оцен- 
ками. Исследуйте мертвые зоны в оценках. Какие задачи вы забы- 
ли включить? Почему? Для каких действий вам неясно, как провес- 
ти оценку затрат? Что нужно узнать и какие дополнительные 
данные собрать для более точной оценки? Использование меха- 
низма базовой версии, имеющейся во многих инструментах для 
управления проектами, является хорошим способом измерить 
точность оценки. Наконец, поделитесь мыслями, идеями и вопро- 
сами с другими. Разработайте модели для получения хороших оце- 
нок и отправьте их коллегам. Покажите их на конференциях по 
тестированию и управлению проектами. Опубликуйте их в стать- 
ях и книгах. Это поможет вам не только стать лучше, но и оказать 
сообществу тестировщиков услугу, поскольку мы все нуждаемся 
в улучшении оценок затрат. 


Обдумайте, какие есть препятствия. В предыдущих разделах опре- 
делено несколько возможных препятствий для получения хоро- 
ших оценок. Не все из них применимы в вашем случае. Рекомен- 
дую потратить время на выявление проблем в рамках вашего 
контекста, которые могут помешать выбору эффективных прак- 
тик оценки затрат. Выработайте идеи по преодолению этих пре- 
пятствий. Если некоторые идеи не срабатывают так, как должны, 
не сердитесь и не опускайте рук (по крайней мере, надолго); про- 
сто измените подход и попытайтесь применить его в следующем 
проекте. Поскольку книга Фреда Брукса “Мифический человеко- 
месяц" по-прежнему актуальна, спустя 25 лет после первого изда- 
ния, значит, описанные им проблемы непросты, и вы не решите 
их за один подход. 


Практикуйтесь, практикуйтесь, практикуйтесь. С каждым разом, 
когда вы начинаете составлять декомпозицию работ, бюджет, стро- 
ить бизнес-план на основе окупаемости инвестиций в тестирова- 
ние, обсуждать время и ресурсы с руководством для получения оце- 
нок и управлять проектом в соответствии с этими оценками, вы 
обнаруживаете, что это получается все лучше и лучше. Настойчиво 
делайте это и после завершения каждого проекта спрашивайте 
себя, что вы узнали нового об оценке затрат. 


Используйте по максимуму то, что есть в наличии. Если вам нужна 
практика, вы должны хотеть практиковаться. Если вас просят про- 
вести тестирование с недостаточными ресурсами, не терзайтесь 
при отказе. Практически всегда ищется компромисс. Если от вас не 
хотят ничего противозаконного или неэтичного, вероятно, в ва- 
ших интересах держаться в проекте до конца. Я научился многому 
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в оценке затрат и в проектах, которые закончились катастрофой, 
и в проектах, которые прошли успешно. 


Располагая утвержденной оценкой затрат, можно перейти к следую- 
щему этапу. В следующих двух главах мы рассмотрим планированиетести- 
рования. Каково то множество деталей, которые необходимо собрать 
вместе для успешного проекта? Если рассматривать оценку затрат как 
карту, то план проведения тестирования — это направления движения по 
ней. Но в этом случае направления движения имеют отношение к группе 
водителей, которые должны приехать в одно и то же место, не столкнув- 
шись друг с другом или с кем-нибудь еще. Как этого добиться? 


ГЛАВА 6 


Изучение и обсуждение 
содержания проекта: 
планирование тестирования 


Н екоторые менеджеры уверены, что планирование завершается, как 
только они подготовили и утвердили у руководства декомпозицию 
работ, график и бюджет. Хотя я согласен с тем, что качественная оценка 
затрат, которую поддерживает руководство, имеет большое значение для 
написания эффективного плана для любого проекта, в рамках процесса 
оценки затрат множество деталей остается скрытым, непознанным и не 
доведенным до заинтересованных лиц. При подготовке оценки мы дела- 
ем допущения, определяем зависимости, перескакиваем через конкрет- 
ную работу и принимаем за аксиому, что определенные процессы низше- 
го уровня просто имеют место. Это опасно, если мы берем за основу 
непосредственно подпроект тестирования в контексте рабочей группы 
проекта, который определяет, что мы делаем, почему мы это делаем и как 
мы зависим друг от друга. 

Но откуда возьмется тревога в рабочей группе проекта, если мы сначала 
не проникнемся ею сами и затем не просветим наших коллег? Подпроекты 
тестирования состоят из сети сложных, взаимозависимых временных ак- 
тивностей, которые увязаны со многими другими активностями в объемлю- 
щем проекте. Даже опытные тест-менеджеры сталкиваются с трудностями, 
предугадывая детали того, что будет происходить. Чтобы работать в реаль- 
ном мире, необходимо вникнуть в суть мелочей. Как только мы это сделаем, 
мы должны обсудить наше понимание с другими и получить их поддержку. 

В некоторых случаях процесс планирования тестирования имеет 
осязаемый результат — зафиксированный на бумаге план тестирования. 
Этот план может быть частью информации, которую группа проекта 
рассчитывает получить от группы тестирования. Для удобства понима- 
ния документированных планов тестирования проектная группа может 
предполагать, что план тестирования будет разработан в соответствии 
с некоторым шаблоном, разработанным внутри компании либо являю- 
щимся стандартом в отрасли. В других случаях план тестирования мо- 
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жет появиться в виде небольшого документа, а то и вовсе не фиксиро- 
ваться на бумаге. В этой главе будем предполагать, что мы намерены 
подготовить документированный план тестирования. В противном слу- 
чае наибольшее значение имеет то, что группа тестирования понимает, 
что делать, а проектная группа согласна поддержать план и приняла ре- 
зультаты планирования как достаточные. 


Процесс планирования тестирования 


Процесс 5 — это процесс, который я использую для планирования тести- 
рования. Шаблон плана тестирования, который вы применяете, или спо- 


Процесс 5. Процесс планирования тестирования 


№ этапа Этап Выполнено? 
1. Исследовать, продумать, собрать и документировать стра- п 
тегию, тактику и составляющие работы подпроекта тести- 
ані ДОВАНИЯ о здо 


2. Обсудить и документировать совместные работы подпро- О 
екта тестирования и объемлющего проекта разработки. 
3. Завершить подготовку и документирование оставшихся О 


логических деталей и подробностей плана, в том числе 
рисков самого подпроекта тестирования и определений 
глоссария тестирования и проекта. Указать все цитируе- 
мые документы. Подготовить одностраничное резюме 
подпроекта. ования. 


4. Разослать план для закрытого (автономного) рецензиро- О 
вания, обычно сначала сотрудникам группы тестирова- 
ния, а затем на более широкое обсуждение среди заинте- 
ресованных лиц и участников проекта. Собрать отзывы и 
пересмотреть план, повторив этапы 1 — 3 по необходимо- 
сти. Изучить любые изменения в имеющемся графике и 
бюджете (превышающие оговоренные резервы времени 
и планы на случай непредвиденных обстоятельств), вне- 
сенные в результате процесса планирования, и получить. 


поддержку этих изменений у руководства. 
5. Разослать план для открытого рецензирования. Провести п. 


совещание по итогам рецензирования с участием всех за- 
интересованных лиц. Сделать все необходимые заключи- 
тельные уточнения и удостовериться, что с учетом всех со- 
гласованных на совещании изменений план для подпроек- 
та ования за ванна и ен. 


6. Пересмотреть оценку графика и бюджета на основе новой п 
информации, полученной в ходе процесса планирования, 
включая использование ресурсов. Если в результате про- 
исходит сдвиг сроков или увеличение бюджета за пределы 
резервов или планов на случай непредвиденных обстоя- 
тельств, эскалируйте проблемы для решения на соответст- 
вующий уровень руководства. Обсуждение новых бюджета 
играфика может повлечь повторение этапов планирова- 
ния или перера оценки т. 


т. Поместите план в библиотеку проекта или в систему О 
управления конфигурацией. Ведите контроль измене- 
ний документа. 


Глава 6. Изучение и обсуждение содержания проекта 155 


мы, предназначенной для те 


соб, который вы выбираете для документирования плана тестирования, 
может определенным образом повлиять на содержание и порядок шагов. 
Например, некоторые процессы тестирования требуют разработки гене- 
рального плана тестирования (тазег ќеѕє рІап) для всего тестирования 
в проекте и отдельных частных детализированных планов тестирования 
для каждой фазы или уровня тестирования (например, комплексного 
и системного тестирования). Информация, попадающая в каждый из до- 
кументов, оказывает влияние на ход процесса планирования тестирова- 
ния и может означать, что в результате мы получаем два-три процесса пла» 
нирования тестирования, проходящих одновременно. 


У Джамала есть план 


Джамал начал готовить план 12 сентября, но 17 сентября, утвердив пере- 
смотренную финальную версию оценки затрат, он взялся за план всерьез. 
Он начал с обзора результатов анализа рисков качества и документирова- 
ния рамок тестирования в таблице с колонками ДА /НЕТ. Каждый риск, 
для которого заинтересованные лица рекомендовали полное и сбаланси- 
рованное тестирование, отправлялся в колонку ДА, а риски более низко- 
го приоритета помещались в колонку НЕТ. 

Затем Джамал приступил к выбору подходящей стратегии тестирова- 
ния для каждого риска качества, попадающего в рамки тестирования. Он 
уже принял решение по поводу некоторых стратегий при составлении де- 
композиции работ. Например, его группа будет использовать автомати- 
зированное тестирование для большей части функционального тестиро- 
вания и для тестирования производительности. Однако некоторые 
детали оставались невыясненными, итеперь он приступил ких обдумыва- 
нию. Тестирование обработки ошибок и восстановления системы после 
сбоев, по его представлению, должно включать в себя полный обзор сооб- 
щений об ошибках, определенных для серверной и клиентской сторонах 
системы, и, вероятно, должно основываться на просмотре исходных фай- 
лов сообщений, а не на попытках исчерпывающим образом смоделиро- 
вать каждый вид сбоя. Тестирование нагрузки, производительности 
и объема, вероятно, потребует инструментов для работы с АРГинтерфей- 
сом, чтобы общаться с АРІ на стороне сервера, и потребует смоделиро- 
вать определенные виды нагрузки в дополнение к готовым коммерче- 
ским инструментам нагрузочного тестирования на основе графического 
интерфейса. 
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По мере решения некоторых проблем он начал аккумулировать состав 
тестовой среды. Бюджет позволял ему приобрести один дополнительный 
серверный кластер, который Джамал планировал добавить к трем уже 
имеющимся кластерам, оставшимся от предыдущего проекта для 5реєду- 
Утиег версии 3.0. (Он планировал оставить один из четырех кластеров 
для проекта ЅреейуМгісег 3.0, предназначенный специально для тестиро- 
вания сопровождения.) Поскольку предполагалось выполнять большие 
объемы ручного и автоматизированного тестирования одновременно, 
он запланировал приобрести десять дополнительных клиентских систем 
помимо тех пяти, которые можно было забрать из подпроекта тестирова- 
ния ЗреедуМткег 3.0. Джамал получил эти цифры, основываясь на пред- 
ставлении, какой объем тестирования будет выполняться в каждый опре- 
деленный момент и можно ли раздельно использовать серверные 
кластеры для разных видов тестирования или нужно для каждого вида 
тестирования иметь свой собственный кластер. 

Джамал просмотрел исходные оценки, подробно исследуя, какие тес- 
ты на каких конфигурациях будут исполняться. Используя тот же метод 
анализа, что и при получении оценок, но фокусируя внимание на загрузке 
серверов и рабочих станций в часах, а не на общей продолжительности 
работ, Джамал еще раз убедился, что ему нужны четыре серверных кла- 
стера и восемь дополнительных рабочих станций (см. рис. 6.1). В вычис- 
лениях в нижней части таблицы он проверит, что четыре кластера учте- 
ны только один раз. 

Джамал очень обрадовался, обнаружив, что детальные расчеты пока- 
зывают, что предварительные грубые оценки затрат на аппаратуру доста- 
точно точны и умеренны. Но какая конфигурация (аппаратное, про- 
граммное и сетевое обеспечение) будет у тестовой среды? Джамал решил 
построить диаграмму, чтобы визуально представить тестовую среду. 

При построении диаграммы конфигурации тестовой среды Джамал 
пришел в замешательство. Дополнительный серверный кластер помес- 
тится в лаборатории, поскольку три системы можно расположить в стой- 
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Рис. 6.1. Начальный подробный план использования оборудования 
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ке, но пять из десяти дополнительных рабочих станций некуда ставить. 
Дополнительного места в лаборатории не было, а Джамалу не хотелось 
разносить оборудование по разным помещениям. Если попытаться раз- 
местить все рабочие станции в лаборатории, сотрудникам не останется 
пространства для работы. “Хм, ~ думал он, - что же делать?” Невозможно, 
чтобы тест-менеджер, три тестировщика и четыре младших тестировщи- 
ка работали одновременно на десяти рабочих станциях, поскольку в этом 
случае нельзя заниматься локализацией дефектов, написанием отчетов о 
них и читать электронную почту, пока выполняются тесты, и т.п. Его 
опыт показывал, что две рабочие станции на сотрудника — хорошо рабо- 
тающее эмпирическое правило. Как получить это соотношение? 

Он вспомнил обучающий курс по руководству тестированием, на кото- 
ром рассказывалось про использование младших тестировщиков, рабо- 
тающих по контракту, во вторую смену. “Предложите дополнительную 
оплату за час-два работы в неудобную смену, — говорил инструктор. — 
И увас не должно быть проблем с поиском контрактников для работы в 
вечерние часы”. “Хм, — подумал Джамал, — посмотрим, что из этого полу- 
чится”. Он переработал план использования оборудования из расчета 80- 
часовой (а не 40-часовой) рабочей недели. (В среднем тестировщик тра- 
тит 30 часов в неделю на выполнение тестов из-за совещаний, обсужде- 
ний в группе и т.п., но сами рабочие станции должны быть доступны для 
проведения тестирования в течение всего рабочего времени в обеих сме- 
нах.) Результат, как показано на рис. 6.2, позволяет достичь цели за счет 
уменьшения количества необходимых рабочих станций примерно до 10. 
В любой момент число работающих в тестовой среде тестировщиков не 
превысит пяти человек, что в точности соответствует отношению 2:1 ме- 
жду числом рабочих станций и числом тестировщиков. Пересмотрев 
бюджет, Джамал увидел, что экономия на покупке рабочих станций прак- 
тически покроет премии за работу в вечернюю смену, которые он запла- 
тит младшим тестировщикам, работающим по контракту. Перерасход 
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Рис. 6.2. Пересмотренный подробный план использования оборудования 
с учетом двухсменной работы 
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Рис. 6.3. Тестовая среда проекта “Суматра” 
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средств составит около $4000, что вписывается в 10% средств на непред- 
виденные расходы. Джамал вновь переработал диаграмму конфигурации 
тестовой среды (см. рис. 6.3). 

“Хорошо, я разобрался со средой, — думал он, — но кто будет выпол- 
нять тесты?” К этому моменту он определил двух штатных сотрудников 
(Лин Цу и Эмму), одного нового тестировщика, которого предстоит на- 
нять, и четырех младших тестировщиков, которых возьмут на работу по 
контракту на период тестирования в проекте. Теперь было уже понятно, 
что младшие тестировщики будут работать в две смены. Джамал зафикси- 
ровал эту информацию, а также различные следствия из нее в плане тес- 
тирования. 

Джамал вновь обратился к декомпозиции работ. Во-первых, он нашел 
в графике Гантта все основные контрольные точки, уделяя особое внима- 
ние зависимостям от других групп, например получение версий на тести- 
рование, и включил их в план тестирования. Он исправил ошибку в началь- 
ной версии декомпозиции работ, связанную с некоторыми тестовыми 
циклами системного тестирования продолжительностью более одной не- 
дели. Сначала он немного огорчился, но затем понял, что даже экспертная 
оценка и тщательная проверка не способны устранить все ошибки ни в ис- 
ходном коде, ни в планах проекта. 

Он начал подробно обследовать каждую задачу, каждую активность, 
каждый процесс, включенные в декомпозицию работ. В разделе, посвя- 
щенном разработке тестов, он упомянул не только конкретные области, 
на которые необходимо нацелить новые тесты, но и подробные сведе- 
ния о том, как эти тесты разработать. В частности, он выделил основной 
элемент работ по созданию тестов -- разработку тестов безопасности и 
секретности. Эти тесты предназначены для тестирования вручную. Их 
будет выполнять Лин Цу, используя графический интерфейс (браузер), 
различные АРГ-интерфейсы, командные строки МТ и О МХ и интерфей- 
сы баз данных. Тесты будут нацелены на проверку как структуры кода, 
так и поведения системы. Лин Цу будет разрабатывать тестовые данные, 
тестовые сценарии, макросы, скрипты, процедуры и т.п. Он также рас- 
считывает, что Лин Цу исследует известные уязвимые места в системах, 
построенных на базе браузеров. Такая степень детализации вместе со 
стратегиями тестирования, представленными ранее, по расчетам Джа- 
мала, позволит Эмме, Лин Цу и новому тестировщику получить доста- 
точно информации о том, какие виды тестов необходимо разработать. 
И, таким образом, он может оставить им вопросы детального проекти- 
рования и разработки тестов. 

Из плана тестирования для бреедуМиег 3.0 Джамал скопировал в но- 
вый план разделы об отслеживании дефектов и тестовых сценариев. Этот 
раздел описывает используемые поля системы отслеживания, но не со- 
держит никакого подробного описания процессов выполнения тестов 
и написания отчетов о дефектах. Чтобы удостовериться в том, что вновь 
принятые тестировщик и младшие тестировщики понимают, как устрое- 
ны эти критические процессы, Джамал решил провести однодневное  обу- 
чение, сразу после того как они прасета к работе, с раздачей слайдов 
и сзаписями лекций. 
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Часть І, Планирование 


Младшие тестировщики, вероятно, не очень хорошо разбирающие- 
ся в тестировании, получат кураторов из числа инженеров-тестиров- 
щиков. (Он пометил для себя: не забыть раздать инженерам-тестиров- 
щикам заметки о том, как стать хорошим куратором, а также перечитать 
их самому, поскольку он будет курировать вновь принятого на работу 
инженера-тестировщика.) Куратор должен проверять все результаты 
тестирования и отчеты о дефектах, полученные младшим тестировщи- 
ком. Джамалу нравилось, как шла работа в этом направлении в проекте 
БреедуУУгігег 3.0. Сделав несколько небольших изменений, чтобы следо- 
вать линии предыдущего проекта, Джамал завершил первый большой 
этап планирования тестирования — документирование внутренних ас- 
пектов тестирования. 


№ этапа Этан . Вьшолнено? 
1. Исследовать, продумать, собрать и документировать страте- 
гию, тактику и составляющие работы подпроекта тестирова- 
ния. 


Теперь переходим к трудоємкой части: подготовке беспрепятствен- 
ной передачи результатов и процессов совместной работы с остальной 
частью группы проекта. Для начала Джамал посчитал полезным нарисо- 
вать картинку (см. рис. 6.4), иллюстрирующую, каким образом происхо- 
дит взаимодействие тестировщиков с заинтересованными лицами, вклю- 
чая разнообразные потоки информационных продуктов и услуг вне 
группы тестирования и передаваемые материалы и услуги тестирования 
в группы. 

“Хорошо, — думал Джамал, — сейчас я просто должен договориться 
о том, как будут идти потоки внутрь и за пределы группы тестирования”. 
Сначала он позвонил Кейту Ли, менеджеру системных операций и адми- 
нистрирования. У него было два вопроса к Кейту, один требовал немед- 
ленного ответа, другой предполагал более длительные раздумья. 

“Привет, Кейт, как дела?” — сказал Джамал, как только Кейт ответил 
ему на звонок. 

“Новый день, новый пожар. Ребята из техподдержки просят помощи 
в конфигурировании странного оборудования заказчика, и вся моя груп- 
па собралась там”. 

“Ясно, у тебя есть мивутка?” 

“Конечно, со временем всегда беда”, — засмеялся Кейт. 

“Поможешь мне в двух вопросах: один срочный, другой нет. Ты же зна- 
ешь, что мы должны довольно скоро начать тестирование первого инкре- 
мента Суматры”. 

“Скоро начать тестирование? Ой, проекттолько начался в этом месяце!” 

“Да, но мы используем итерационный подход. Больше тестируем 
и раньше начинаем. У меня уже есть утвержденные график и бюджет. 


"Бюджет включает в себя закупки оборудования. Если я тебе предостав- 


лю документацию на этой неделе, сможешь ли ты со своей командой на- 
чать работы по конфигурированию прибывающего оборудования для 
тестовой лаборатории, скажем, в среду?” — Джамал сверился со своим 
графиком. 
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Часть І. Планирование 


“Да, часть работы начнем. Серверы требует больше времени, а клиент- 
ские машины — однозначно начнем. Когда мы должны завершить на- 
стройку?” 

Джамал снова взглянул на график Гантта. "1 октября. Начинаем в сле- 
дующий понедельник. Я рассчитываю, что Эмма и Лин Цу приступят к вы- 
полнению некоторых тестов для комплексного тестирования в тестовой 
среде, поэтому мне потребуется помощь твоих людей". : 

“Чем дальше, тем лучше”. 

“Перехожу к следующему вопросу. Я бы хотел, чтобы ты выделил двух 
человек из своей группы в качестве ключевых контактных лиц для разре- 
шения проблем тестовой среды. Это позволило бы иметь четкое направ- 
ление для эскалации проблем”. 

"Так, для серверов я бы выделил Петру Фейхимян (Реїга Еаһітіап). 
Она недавно работает, но уже зарекомендовала себя. Для клиентских ма- 
шин, что ты думаешь по поводу кандидатуры Индера Ванешватана (Іадег 
Уапеѕћмаѓап)?” — спросил Кейт. 

“Хм, — осторожно сказал Джамал, — знаешь, Кейт, в проекте Ѕрееду- 
МУгігег 3.0 был случай, когда Индер неверно настроил все клиентские 
машины, и мы потеряли неделю тестирования. Буду откровенен с то- 
бой, Кейт. Тот случай и то, как он отреагировал на наше беспокойство, 
произвело сильное впечатление на меня и на других сотрудников моей 
группы”. 

“Понимаю тебя. У меня был с ним серьезный разговор обо всей ситуа- 
ции и о его реакции. Это снова не повторится. Индер обещал мне, и я обе- 
щаю тебе. Конечно, если что-то действительно произойдет, передай про- 
блему мне. Пожалуйста, проверь, что твои люди знают об этом. Если 
Индер или Петра не займутся твоей проблемой в течение получаса после 
твоего звонка или сообщения на мой пейджер, сразу звони мне”. 

“Хорошо, Кейт, ты был довольно откровенен. Я включу процесс эска- 
лации в план тестирования. Посмотришь на этой неделе первую версию 
плана? Сообщи, если обнаружишь проблемы”. 

“Будь уверен, брат. Вернусь к своим сегодняшним проблемам,” — язви- 
тельно хихикнул Кейт. 

“Пока”, — сказал Джамал. Он повесил трубку и подумал, что одно 
дело сделано, осталось еще два. Он снова снял трубку и позвонил 
Дженни Кауфман, чтобы обсудить порядок эскалации блокирующих 
ошибок и передачи отчетов об ошибках. Потом он позвонил Ясухиро 
Канагаве (Хазибіго Капарама) и обсудил процесс передачи версии на 
тестирование. 

После отработки интерфейсов с группами своих коллег Джамал пере- 
шел к изучению вопросов о критериях начала и заверщения тестирова- 
ния, а также о подготовке отчетов о состоянии дел. Джамал работал под 
началом Джона Албертсона чуть более года, поэтому он знал, что Джон 
будет настаивать на таких отчетах. Гарольд Джоунз пришел в компанию 
недавно, поэтому Джамал не знал, что ожидает Гарольд от тестировщи- 
ков. Но Джамал решил не спрашивать его, а взять на себя подготовку про- 
екта критериев и затем отправить его вместе с инструментальной пане- 
лью состояния дел в тестировании из проекта ЅреейуМ/гісег 3.0. 
(Подготовка отчета о ходе тестирования и инструментальная панель рас- 
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Критерии начала комплексного тестировании 


Комплексное тестирование должно начинать- 

ся при выполнении следующих условий: 

1. Система отслеживания ошибок установле- 
‚наи доступна для использования группам 
поддержки разработок и системных разра- 
боток. 

2. Группа системных операций и администри- 
рования завершила настройку клиентских 
рабочих станций и серверов для тестирова- 


ния. Группа тестирования получила необхо- 


димый доступ к этим системам. 


3. Группа разработки подготовила по крайней 


мере два взаимодействующих компонента 


системы для передачи на комплексное тес- : 


тирование под формальным автоматизиро- 
ванным контролем системы управления 
конфигурациями. ` 


4. Группа разработки или группа сборки вер- 


сий подготовила тестовую версию, содержа- 


щую по крайней мере два взаимодействую- 
щих компонента, прошедших компонент- 
ное тестирование. 

5. Группа разработки подготовила перечень 
изменений, которые описывают функцио- 
нальность тестовой версии. 


Критерии продолжения комплексного | 
тестирования | 


Комплексное тестирование должно быть про- 

должено при условии выполнения следующих 

критериев: 

1. Каждая версия, предназначенная для ком- 
плексного тестирования, содержит только 
компоненты, находящиеся мод формаль- 


ным автоматизированным контролем систе- 


мы управления конфигурациями. 

2. Группа разработки или группа сборки вер- 
сий подготовила тестовые версии из взаи- 
модействующих компонентов, прошедших 
компонентное тестирование. 


3. Группа разработки сопровождает каждую · 


тестовую версию перечнем изменений, 
которые описывают функциональность 
‚версии. | | 
4. Существует тестовая версия, собранная из 
относительно нового кода, которая может 
быть установлена в тестовой среде таким 
образом, что она будет стабильно функцио- 
нировать. Более того, группа тестирования 
. может проводить плановое и исследова- 
тельское тестирование тестовой версии 
в относительно эффективной манере, по- 


зволяющей получить в дальнейшем поддаю- 


. щиеся интерпретации результаты тестиро- 
вания. 


Критерии завершения комплексного 
тестирования 


Комплексное тестирование считается успешно 
завершенным при выполнении Следующих ус- 
ловий: р 
1. Группа тестирования выполнила все запла- 
нированные тесты относительно всех за- 
планированных версий для комплексного 
тестирования. 
2. Заключительная версия, предназначенная 
для комплексного тестирования, содержит 
- все компоненты, которые войдут в версию 
атры, предназначе для польвовате- 
сж ( іі Ааа) 
$. Группа управления проектом «Суматра» 
считает, что выполненное комплексное тес- 
тирование достаточно, и дальнейшее про- 
должение комплексного тестирования, по 
всей вероятности, не выявит новых дефек- 
тов, связанных с интеграцией компонентов. 
4. Группа управления проектом «Суматра» 
провела совещание, посвященное заверше- 
нию фазы комплексного тестирования, 
и приняла решение о том, что критерии за- 
вершения тестирования выполнены. 


Критерии начала системного тестирования. 


Системное тестирование может быть начато 

при выполнении следующих условий: 

1. Система отслеживания ошибок установлена 
и доступна всем участникам проекта. 

2. Группа системных операций и администри- 
рования завершила настройку клиентских 
рабочих станций и серверов для системного 
тестирования. Группа тестирования получи- 
ла необходимый доступ к этим системам. 

3. Г работки завершила 
анай й и исправление Чорай за- 
планированных для инкремента 1, и помести- 
ла все указанные компоненты исходного кода 
под формальный автоматизированный кон- 
троль системы управления конфигурациями. 

4. Группа разработки шила компонент- 

‚ ное тестирование всех функций и исправле- 
ние всех дефектов, запланированные для 
инкремента. ` 

5. Открыто менее 50 ошибок, подлежащих 

"обязательному исправлению (согласно ре- 
шению группы управления проектом), | 
включая ошибки, обнаруженные в ходе ком- 
понентного и комплексного тестирования. 

6. Группа управления проектом «Суматра» 

" провела совещание по поводу начала фазы 
системного тестирования и приняла реше- 
ние, что инкремент 1 готов к системному 
тестированию. 

7. Группа сборки версий подготовила полную 
версию с контролируемыми изменениями 
для группы тестирования, согласно описа- 
нию в разделе «Версионное управление». 


Рис. 6.5. Критерии начала, продолжения и завершения комплексного 
и системного тестирования 
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Критерии продолжения системного 
тестирования 


Системное тестирование должно быть продол- 
жено при условии выполнения следующих кри- 
териев: 


1. Все программное обеспечение, передавас- 
мое на тестирование, сопровождается доку- 
ментированным перечнем изменений. Пе- 
речень изменений должен содержать спи- 
сок отчетов о дефектах, которые, по мне- 
нию группы разработки, исправлены в каж- 
дой из версий. 


2. В системе “Суматра” не производится ника- 
ких изменений, т.е. не меняются исходный 
код, файлы конфигурации, пользователь- 
ская документация и другие инструкции по 
настройке и процессы, без сопровождающе- 
го сообщения об ошибке или как элементы 
планируемых свойств или исправлений 
ошибок в следующей версии. 

3. Группа сборки версий еженедельно предос- 
тавляет контролируемую полную версию 
программного обеспечения группе тестиро- 
зания, созданную на основе относительно 
нового исходного кода, согласно описанию 

- в разделе “Версионное управление”. Эти 
версии могут быть установлены в тестовой 
среде таким образом, что они будут стабиль- 
но функционировать. Более того, группа 
тестирования может проводить плановое 
и исследовательское тестирование тесто- 
вой версии в относительно эффективной 
манере, позволяющей получить в дальней- 
шем поддающиеся интерпретации результа- 
ты тестирования. 


4. Открыто менее 50 ошибок, подлежащих 
обязательному исправлению (согласно ре- 
шению группы управления проекта), вклю- 
чая ошибки, обнаруженные в ходе компо- 
нентного и комплексного тестирования. | 

5. До завершения фазы системного тестирова- 
ния дважды в неделю проводятся совеща- 
ния, посвященные управлению незавершен- 
ными работами по устранению дефектов 
и временем закрытия дефектов. 


Часть І. Планирование 


Критерии завершения системного 
тестирования 


Системное тестирование успешно завершено 

в случае выполнения следующих критериев: 

1. В предшествующие четыре недели не про- 
изошло ни одного сбоя, остановки, неожи- 
данного прекращения процесса или другой 
остановки обработки на программном и ап- 
паратном обеспечении серверов. 

2. Инкремент, являющийся кандидатом в з0- 
лотую сборку (в настоящее время планиру- 
ется, что это будет инкремент 5), подвергал- 
ся системному тестированию в течение шес- 
ти недель. 

3. Группа тестирования выполнила все запла- 
нированные тесты относительно тестовой 
версии системы, являющейся кандидатом 
в золотую сборку. 

4. Группа тестирования исправила все ошиб- 
ки, подлежащие обязательному устранению. 

5. Группа тестирования удостоверилась, что 
все проблемы в системе управления дефек- 
тами либо закрыты, либо отложены и, где 
необходимо, проверены с помощью регрес- 
сионного и проверочного тестирования. 

6. Кривая качества продукта на инструмен- 
тальной панели показывает, что Суматра 
достигла приемлемого уровня качества, ста- 
бильности и надежности. 

7. Значение покрытия рисков качества на ин- 
струментальной панели показывает, что 
все риски качества покрыты адекватным 
образом. 

8. Группа управления проектом согласна, 
что продукт, как это определено в ходе за- 
ключительного цикла системного тести- 
рования, будет удовлетворять разумным , 
ожиданиям качества пользователей и за- 
казчиков. 


9. Группа управления проектом провела сове- 
щание, посвященное завершению системно- 


го тестирования, и согласилась, что крите 
рии завершения системного тестирования 
выполнены. 


Рис. 6.5. (продолжение) 


сматриваются в главе 15.) Перечень предлагаемых Джамалом критериев 
приводится на рис. 6.5. Он отправил сообщение с критериями и описани- 
ем инструментальной панели Джону и Гарольду с копией вице-президен- 
ту по продажам Сесиль Райс (Сесіїе Вісе), Дженни Кауфман, Кейт Эрнан- 


дес, Кейту и Ясухиро. 
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В тот же день Джамал получил ответ от Гарольда, направленный также 
в качестве копии всем остальным получателям письма Джамала. 


Джамал! 


Проверил прикрепленные файлы. Инструментальная панель. - отлично, но 
объясни мне, пожалуйста, разницу между графиками выполнения работ 
(Еџ1#і11тепё) и хода работ (Ргодгеѕѕ). 


Что касается критериев: они выглядят разумно. Хорошо, что ты понимаешь 
необходимость принятия решений относительно начала и завершения тести- 
рования на уровне управления проектом. На предыдущем месте работы я 
имел дело с менеджером по контролю качества, использовавшим ряд измере- 
ний, которые вели к непродуктивным спорам о серьезности дефектов, 

о значении слова “является” и т.п. :-) 


Два вопроса относительно прекращения тестирования. 


Что это за волшебное число'50 открытых дефектов, при котором происходит 
остановка тестирования? 


Как ты планируешь измерять эффективность, чтобы мы поняли, что такая 
эффективность подходящая? 


Отличная работа, Г. 


Джамал отправил ответ с копией всем получателям. 
Привет, Гарольд! 


Рад, что тебе понравилось. Если ты не против, поговорим 0б инструмен- 
тальных панелях завтра? 


Относительно решений уровня управления проектом. Да, критерии начала, 
продолжения и завершения фаз тестирования должны учитывать не только 
вопросы качества, но и варианты свойств, бюджета и сроков. 


По поводу замечания, 50 не является волшебным числом, но совещания, по- 
священные расстановке приоритетов исправления дефектов, становятся не- 
управляемыми при наличии примерно такого числа открытых дефектов. Мой 
опыт показывает, что нет никакого смысла продолжать тестирование, если 
невозможно управлять основным результатом работы тестировщиков - отче- 
тами о дефектах. Верно? 


Что же до измерения эффективности, это часть того, что нам покажет гра- 
фик хода работ. Если нам потребуется для прогона тестов в три-четыре 
раза больше времени, чем мы планировали, что мы, безусловно, увидим на 
графике, думаю, мы захотим рассмотреть другие варианты дальнейшей рабо- 
ты, Снова подчеркну, это должно быть бизнес-решение о балансе качества, 
свойств, бюджета и сроков. Я бы. лучше не прекращал тестирование, одна- 
ко, если не будет достигнуто никакого продвижения вперед, по-моему, мы 
должны обсудить на уровне управления проектом, имеет ли смысл продол- 
жать тратить наши ресурсы. 


Надеюсь, я ответил на твои вопросы. 
С уважением, 


Джамал 
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Через 15 минут Джамал получил ответ на свое сообщение, с копией 
всем участникам дискуссии. 


Джамал, 


Все совершенно понятно. Пожалуйста, рассматривай критерии как “офици- 
ально одобренные. Гарольдом”. 


Пока, 
Г. 

"Мезтапа Этап : й Вьшолнено? 
2. Обсудить и документировать совместные работы подпроекта 


тестирования и объемлющего проекта разработки. 


“Отлично, — думал Джамал, — яуже почти закончил план, но что может 
пойти не так? Что я могу сделать для смягчения рисков, и если случится 
что-нибудь плохое, могу я запустить план на случай непредвиденных об- 
стоятельств, чтобы снизить ущерб?” Он снова обратился к предыдущим 
проектам, просмотрел базы данных управления изменениями некоторых 
последних его проектов и добавил несколько рисков, а также план на слу- 
чай непредвиденных обстоятельств и план смягчения рисков. Он некото- 
рое время сидел, уставившись в стену, а затем добавил еще несколько рис- 
ков. Джамал пролистал несколько книг о тестировании, которые лежали 
на его столе, и затем дописал еще риски". В таблице 6.1 показано, над чем 
размышлял Джамал. 


№ этапа Этап Выполнено? 
3. Завершить подготовку и документирование оставшихся логи- 


ческих деталей и подробностей плана, в том числе рисков са- 
мого подпроекта тестирования и определений глоссария тес- 
тирования и проекта. Указать все цитируемые документы. 
Подготовить одностраничное резюме подпроекта тестирова- 
ния. З 


После составления списка рисков Джамал приступил к включению за- 
дач и напоминаний в программу для составления плана-графика работ, 
чтобы можно было выяснить, наступили ли события рисков. Вычисление 
местоположения этих мин замедленного действия — одна из лучших час- 
тей плана, думал он. Как бы было хорошо, если бы мне удалось не насту- 
пить на эти мины! Джамал завершил подготовку плана определением 
ряда терминов, перечислением ссылок на цитируемые и вспомогатель- 
ные документы и написанием краткого резюме. Тем же вечером, 18 сен- 
тября, в среду, перед уходом домой Джамал отправил первый вариант 
плана тестирования в качестве прикрепленного файла Джону Албертсо- 


1 База данных управления изменениями рассмотрена в главе 7 моей книги "Матаріте ійе 
Тент Росез5, Зесопа Енот’. Кроме того, в главе 11 той же книги обсуждаются факторы, 
влияющие на ускорение и замедление тестирования. К последним относятся также риски, 
которые должны быть смягчены. 
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Таблица 6.1. Риски, непредвиденные обстоятельства и их смягчение для 
„ Проекта 5реедум/гіег 


Риск 


Сбой в процессах решения 
или эскалации проблем 


Внешние исполнители не 
могут установить Суматру. 


Серьезные изменения в тре- 
бованиях, архитектуре, свой- 
ствах или других частях пла- 
на разработки, сделанные 

в последнюю минуту. 


После начала тестового цик- 
ла обнаружилось, что тесто- 
вая версия не готова к тести- 
рованию. 


Подготовка тестовой среды 
не завершена к дате начала 
комплексноге или системно- 


го тестирования. 


Непредвиденное обстоятельство/Смягчение | 


Попытаться найти обходное решение проблемы, учесть не- 
эффективный ход работ и задержки в выполнении планов. 


Или 

Остановить тестирование в соответствии критерием 
продолжения тестирования, решить процессуальную 
проблему. 

Или 


Продолжить тестирование обходным путем, разрешить 
проблему при следующем ее возникновении. 


Предотвратить возникновение проблемы за счет тщатель- 
ного тестирования установки перед отправкой версии 
внешним исполнителям. А 


Или 

Подготовить отчет о дефекте в процессе установки. 
и | | 
Отправить опытного специалиста для установки. 


Учесть возрастание рисков качества из-за неполного тести- 
рования изменения. | 


Или 
Принять риск увеличения бюджета из-за добавления со- 


трудников или аутсорсинга для выполнения достаточного 
тестирования в последний момент. 


Или 


Принять риск увеличения сроков за счет откладывания дат 
выпуска. 


.Ввести автоматизированное приемочное тестирование на 


уровне подготовки сборки для определения неготовых вер- 
сий. 


Или 


Прекратить тестирование в ходе “неудавшегося” цикла, 
вернуться к “последней хорошей” версии и продолжить 
тестирование с учетом сокращения выполнения заплани- 
рованных тестов и снижения темпов хода работ. 


Начать тестирование с использованием тех тестов, кото- 
рые могут исполняться в доступной среде, учитывая огра- 
ниченные возможности выполнения тестов, невысокий 
темп хода работ и значительные пробелы в покрытии тес- 
тами. 


Или 


Отложить плановые сроки начала и завершения фазы тес- 


тирования в соответствии с реальными сроками готовно- 
сти тестовой среды. 
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а | Таблица 6.1 (продолжение) 


Риск 


Тестовая среда не является 
полной для одной или двух 


фаз. 


Поддержка тестовой среды 
недоступна или не является 
квалифицированной. 


Передаваемые материалы, 
содержащие ошибки, пре- 
пятствуют ходу тестирова- 
ния, или снижают тестовое 
покрытие, или и то и другое 
вместе. ? 


Непредвиденное обстоятельство /Смягчение 


Переработать план с учетом необходимого продления фаз, 
исключить все тесты, зависящие от неготовых конфигура- 
ций, выявить возрастающие риски, 

Или 


Установить третью (ночную) смену. (МВ! Это решение не- 
обходимо принять до найма младших тестировщиков. Оно 
не гарантирует полного смягчения рисков.) 


Учесть снижение темпов хода работ и невыполнение за- 
планированных тестов. 


Или 
Нанять на короткий период контрактника для получения 
квалифицированной и своевременной поддержки. 


Предотвратить‘проблемы за счет тщательного компонент- 
ного тестирования силами группы разработки. 
Или 


Придерживаться критериев продолжения и остановить 
тестирование, если проблемы станут серьезными. Учесть 
задержку работ. 

Или 

Попытаться продолжить тестирование в соответствии с те- 


кущим графиком и бюджетом с учетом ухудшения качества 
версии для заказчика. 


Пробелы в тестовом 
покрытии. 


Неясность с вариантами 
использования системы, не- 
полнота информации о сре- 
дах применения системы 
или неверное тестирование. 


Исследовательское (партизанское — риег Ша) тестирова- 
ние позволяет протестировать области, не покрытые за- 
планированными тестами. 

и 


Использовать по возможности методы анализа структурно- 
го покрытия, анализ данных об отказах при эксплуатации, 
данные пользователей для определения пробелов, которые 
необходимо заполнить. Этот вопрос должен, по всей веро- 
ятности, решаться на основе доступности ресурсов в ходе 
проектирования и разработки тестов. 


Получить информацию о реальных вариантах использова: 
ния системы от группы поддержки пользователей, о ре- 
зультатах альфа- и бета-тестирования, организуемого служ- 
бой маркетинга, сведения от группы продаж, а затем разра- 
ботать тесты для покрытия этих областей. 

Или 


Учесть в соответствии с ограничениями сроков и ресурсов 
возможность тестирования, несогласованного с варианта- 
ми использования системы. 


Незавершенность разработ- 
ки, невыполнение критери- 

ев готовности к назначенно- 
му времени. 


Нарушить критерии готовности, сократить объем функ- 
циональности, предоставляемой для тестирования, и вне- 
сти коррективы в план-график проекта. 

Или і 

Нарушить критерии начала тестирования и учесть возрас- 
тание риска низкого качества из-за недостаточного време- 
ни на обнаружение и устранение ошибок, включая риск 
полного провала проекта. 
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К є. - Таблица 6.1 (про, олжение 


Риск Непредвиденное обстоятельство/Смягчение 


Непредвиденная потреб- Увеличить человеческие ресурсы и бюджет. | 
ность в дополнительных ре Или 
сурсах для завершения тести- 


рования. Исключить часть тестирования и перераспределить ресур- 


сы, предназначавшиеся для тестирования пропущенных 
областей. (МВ! Не во всех ситуациях это возможно.) 


Или 


Принять решение не выполнять тесты, для которых не вы- 
делено достаточно ресурсов, и учесть возрастание рисков 
качества, связанных с пробелами в тестовом покрытии. 


Усталость тестировщиков. Принять к сведению временное замедление выполнения 
запланированных тестов. 
и 


Заполнить как можно быстрее вакансии за счет 
тестировщиков-контрактников, имеющих подходящую ква- 
лификацию. 


Усталость ключевых участ- Определить альтернативные варианты или дублеров для 
ников (вне группы тестиро- каждого ключевого участника, не являющегося сотрудни- 
вания). ком грушты тестирования. 

Или 


Заполнить место сотрудником из группы тестирования, 
что влечет за собой неэффективность работы и более мед- 
ленное выполнение запланированных тестов. 


Невозможность нанять под: Использовать все доступные средства для поиска идеально- 
ходящего инженера по авто- го кандидата, включая рекрутинговые компании. 
матизированному тестирова- или 
нию. 

Увеличить продолжительность раунда тестирования, что- 


бы иметь возможность выполнять тесты более медленно. 
Или 
Отправить одного из тестировщиков на ускоренную пере- 


подготовку в учебньй центр производителя инструмента 
тестирования". 


Отладка в тестовой среде. | Предоставить конфигурации в соответствии с требования- 
ми пользователей как для разработки, так и для тестирова- 
ния, вести управление конфигурациями, для того чтобы 

` можно было воспроизвести ошибки в средах разработки. 


Учесть замедление или остановку выполнения план тести- 
рования наряду со снижением эффективности работ из-за 
необходимости восстановления тестовой среды после от- 
ладки. 


а. Я благодарю одного из рецензентов, Дебору Маккандлесс (Оеђогаћ МеСапаїез5) 
из Моіо.сога, за вклад в эту тему. Она написала: “[Для этого вам нужен] кто-нибудь, 
у кого есть все основные умения и навыки, а также желание пройти учебный курс 
и начать. сразу давать отдачу. Это может быть отличной возможностью для кого- 
нибудь существенно продвинуться в карьере. Я проделала этот опытс одним из млад- 
ших программистов, и все получилось отлично”. 


170 


Часть І. Планирование 


ну, Гарольду Джоунзу, Дженни Кауфман, Кейт Эрнандес, Кейту Ли, Ясу- 
хиро Канагаве, Косимо Неграеву, Речел Вудз, Максу дель Оро, Джейму 
Иноджосе и Бобби Макденизлсу. Он также послал копии и Гупте, 
Сайсли Райс и Тине Браун. 


Привет всем! 


К письму прикреплена первая версия плана комплексного и системного тес- 
тирования Суматры. Сопровождающие документы с описаниями графика, бюд- 
жета и результатов анализа рисков можно найти на сервере Јиріїег в пап- 
ке Зиматга/Тезт. 


Понимаю, что все мы занять, однако прошу прислать отзывы в пятницу до 
конца рабочего дня. Я учту ваши отзывы в плане за выходные и подготовлю 
новую версию к понедельнику. Вы все получите приглашение на совещание 
во вторник, чтобы изучить пересмотренную версию плана и принять реше- 
ние. Будет подан обед. (Тина, спасибо за заказ совещания. ) 


С уважением, 
Джамал 


Довольный тем, что неплохая первая версия плана предложена для об- 
суждения вне группы тестирования, Джамал отправился домой. Он знал, 
что, хотя большая часть трудной для подготовки писанины завершена, 
еще предстоит сложная работа по согласованию и утверждению плана. 


№ этапа Этап Выполнено? 


4. Разослать план для закрытого (автономного) рецензирова- М 
ния, обычно сначала сотрудникам группы тестирования, а за- 
тем на более широкое обсуждение среди заинтересованных 
лиц и участников проекта. Собрать отзывы и пересмотреть 
план, повторив этапы 1 — 3 по необходимости. Изучить лю- 
бые изменения в имеющемся графике и бюджете (превышаю- 
щие оговоренные резервы времени и планы на случай непред- 
виденных обстоятельств), внесенные в результате процесса 
планирования, и получить поддержку этих измененийу руко- 
водства. 


За рамками процесса: основные соображения 
по поводу плана тестирования 


Большая часть того, что попадает в план тестирования, — либо результа- 
ты анализа рисков качества или оценки затрат, либо итог обсуждений 
с ключевыми участниками проекта. В первом случае все необходимое мы 
получаем за счет тщательного отбора информации из таблицы анализа 
видов ошибок и их влияния, графика и бюджета и перевода ее в текст или 
картинки. Во втором случае ключевые участники проекта свободны в вы- 
боре ролей и обязанностей, по крайней мере, в рамках ограничений про- 
екта. В обоих случаях план тестирования просто собирает и переформу- 


лирует существующую информацию и дает возможность обмениваться 
этой информацией. 
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Однако тестировщик или тест-менеджер, готовящий план, должен 
тщательно обдумывать некоторые темы. Он должен предлагать идеи, вы- 
воды и решения по этим направлениям таким образом, чтобы люди, про- 
читавшие план, очень четко понимали, что от них требуется. Две такие 
темы, управление подготовкой тестовых версий и отчетность о состоя- 
нии дел в тестировании, будут рассмотрены в последующих главах в каче- 
стве самостоятельных ключевых процессов. (Важно помнить, что эти 
проблемы должны быть учтены в планах.) Сейчас я предлагаю рассмот- 
реть четыре темы, не относящиеся к ключевым процессам: стратегию 
тестирования, планирование ресурсов тестирования, управление конфи- 
гурациями и управление рисками, которые обязательно нужно отразить 
в планах. 


Выбор стратегий тестирования 


Начнем со стратегий тестирования. Что такое стратегия тестирования? 
Разные люди по-разному понимают это выражение. Мое определение 
приведено выше. Для придания смысла контексту стратегии тестирова- 
ния и ее взаимосвязи с целями и тактикой группы тестирования и проек- 
та в целом предлагаю обратиться к рис. 6.6. 

На рис. 6.7 показана стратегия тестирования проекта “Суматра”. Эта 
стратегия, без сомнения, универсальная. Это довольно обычная вещь, по 
крайней мере, как один из экземпляров из определенного семейства стра- 
тегий тестирования. Данное семейство стратегий тестирования поддер- 
живает следующий общий подход. 


в Разработать множество тестов на основе проектирования тестов 
“сверху вниз", используя анализ рисков, требования, цели тестов 
ит.д. 


и Укрепить это множество тестов за счет проектирования “снизу 
вверх” на основе реального использования системы, сценариев ис- 
пользования системы, данных пользователей и т.д. 


во Использовать исследовательское тестирование для заполнения 
очевидных пробелов в покрытии тестами. 


= Применить какой-либо вариант структурного анализа (динамиче- 
ский или статический, например оценку сложности кода) для опре- 
деления скрытых дефектов в тестовом покрытии. 
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> Цель тестирования 


а ротор 
ЕЕ НИ 
ГА 


‘образом тестирование 
приносит выгоду проекту 


Методы, процессы и подходы, применяемые 
для решения конкретных задач тестирования 


Предприятие, направленное на разработку, получение, установку или 
сопровождение системы в рамках контекста, в который вписывается тестирование. 

Для достижения успеха цель, стратегия и тактика тестирования должны соответствовать 

цели, стратегии и тактике всего проекта. 


Рис. 6.6. Цель, стратегия и тактика группы тестирования 


Стратегии тестирования, наряду с этими направлениями, были изуче- 
ны еще в ранних работах по тестированию, в том числе в книге “Искусство 
тестирования программ” Майерса (Муегѕ) и " Сотріеіе Сиіӣе іо Ѕоўѓшате Тезіїпр" 
Гетцеля (Неше]). Они остаются востребованными и сегодня, хотя некото- 
рые варианты не содержат ряда заключительных этапов (т.е. выполняю- 
щихся после нисходящего анализа). 

Однако есть противники этого подхода. Канер (Капег), Бах (Васі) 
и Петтикорд (Решісрога) в “Г.е550т5 Геатпед т Зойшате Тейт?” защищают 
подход, основанный на исследовательском тестировании, управляемом 
рисками. Некоторые сторонники так называемых “быстрых методологий”, 
например’экстремального программирования, говорят о необходимости 
“тестировать все, что может сломаться” под управлением программи- 
стов. Поскольку эти утверждения определяют направления, а не принци- 
пы, они указывают на необходимость тестирования на основе известных 
технологических слабостей. Я рассматриваю такой подход как стратегию 
тестирования на базе архитектуры. 

Другая совокупность решений относительно стратегии относится 
к тому, как и какие тесть группа тестирования должна автоматизировать. 
Дастин (Ризіп), Рашка (Каѕсћка) и Пол (Раці) в книге “Автоматизирован- 
ное тестирование программного обеспечения” продвигают формализованный 
подход к принятию этих стратегических решений. Они называют его ме- 
тодологией жизненного цикла автоматизированного тестирования. Ме- 
нее формализованный подход принятия тех же решений можно найти 
у Фьюстера (Ееузег) и Грэма (Стаһат) в "5о/їшате Тея Ашотанот”. 
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Стратегия тестирования проекта “Суматра” 


Разработать автоматизированные и ручные тесты для покрытия всех рисков качест- 
ва, которые определены как нуждающиеся в полном или сбалансированном тести- 
ровании, с особым вниманием к факторам поведения системы, наблюдаемого со 
стороны некоторого пользовательского интерфейса или доступного программного 
интерфейса приложения (АРТ). 


Добавить тестовые данные или условия в рамках существующих или новых тестовых 
сценариев для покрытия критических вариантов использования системы, пользова- 
тельских данных или известных ыы в нашем продукте или продуктах конку- 
рентов. 

Использовать исследовательское тестирование в областях, которые ранее не были 


покрыты тестами, и которые, с точки зрения интуиции или результатов тестирова- 
ния, представляются областями повышенного риска наличия дефектов. Обновить 


„старые или определить новые тестовые сценарии для покрытия обнаруженных де- 


фектов. 


Провести тестирование на конфигурациях (в тестовой среде), представляющих со- 
бой комбинацию серверов, сетей и клиентских машин, похожих на эксплуатацион- 
ные конфигурации. 

Повторить несколько раз все тестовые сценарии для комплексного и системного 
тестирования, включая функциональные тесты для Зрееду\гиег 3.0, в ходе каждой 
фазы для поиска регрессионной зависимости. 


Насколько позволяют время и ресурсы или предписывает представление о не выяв- 
ленных рисках качества, использовать методы структурного покрытия для опреде- 
ления не подвергавшихся тестированию областей и затем дописать тесты для по- 
крытия критических пробелов в тестовом покрытии. | 


Рис. 6.7. Высокоуровневая стратегия тестирования проекта “Суматра” 


Еще одна часть стратегии — это планируемые киспользованию методы 
тестирования. 


Статические. Тестирование посредством изучения элементов сис- 
темы, например спецификаций требований, архитектуры и исход- 
ного кода. Два известных примера: инспекция кода и рецензирова- 
ние требований. Эта тема подробно обсуждается в “Тйе Рѕусћоіору оў 
Сотриїег Рортаттіпр" Уайнберга (У/еіпЬегр), "бо/їшате Ргојесі биту 
Сша’ Макконнела (МсСоппеП), "5о/їшате Ведилтетет” Вигерса 
(УЛерегѕ) и во многих других работах. 


Структурные (иначе, методы белого или стеклянного ящика). Тестирова- 
ние посредством изучения способа реализации системы. Три обще- 
принятых метода: тестирование потоков данных, тестирование пу- 
тей и тестирование транзакций. Большое число структурных 
методов тестирования приводит Бейзер (Веігег) в "5о/їшате Тезійпр 


Тесітідиез". 


Поведенческие (иначе, методы черного ящика). Тестирование за счет 
изучения свойств системы и поведения, которое она должна демон- 
стрировать. Классические примеры — это эквивалентные разбие- 
ния и тестирование областей (дотла! ге5ціпр). Эти темы подробно 
разбираются в работах Бейзера (Веігег) "Віасі-Вох Тезіїпр" и "5о/їшате 


174 


Часть І. Планирование 


Зузієт Тезіїпр апі Оцаїйу Азбитатсг”, а также у Канера в работе “Тести- 
рование программного обеспечения”. 


и Опытная эксплуатация. Тестирование на основе того, что пользо- 
ватели реально делают с системой. Бета-тестирование, изучение 
удобства использования и, в некоторых случаях, приемо-сда- 
точные испытания — общепринятые методы. Канер (Капег) и др. 
рассматривают опытную эксплуатацию в “Тезйте Сотршет 50/їшате", 
а Нильсен (Міеізеп) подробно исследует удобство использования 
в “Озабииу Епріпеетіпр". 


Эти методы не отличаются резко друг от друга, как вкус сладкого, ки- 
слого, соленого и горького, а, скорее, непрерывно переходят друг в друга, 
аналогично холодному, теплому и жаркому. Например, тесты на основе 
архитектуры, в частности тесты производительности, являются в некото- 
рой степени поведенческими, поскольку нам известно, насколько быстро 
система должна реагировать на определенные ситуации, а также немного 
структурными, так как тестовые условия учитывают известные ограниче- 
ния в технологиях. Из-за их непрерывной природы я предпочитаю рассу- 
ждать об этих категориях в терминах спектра степеней точности опреде- 
ления тестов. 

Вообще говоря, верно, но не обязательно, что первоочередное тести- 
рование в проекте обычно статическое, затем следует структурное, по- 
том поведенческое, и наконец живое. До некоторой степени это случай- 
ность, когда можно начинать определенные виды тестирования, хотя 
также верно, что каждый вид тестирования обычно позволяет найти де- 
фекты определенных типов, которые труднее обнаружить впоследствии 
при применении более грубо определенных тестов. 

Последующие тесты часто позволяют обнаружить ошибки, которые 
с помощью ранее применяемых тестов найти было нельзя. Два приме- 
ра. Ошибки в условиях, такие как использование сравнения “больше” 
вместо “больше либо равно”, наилучшим образом обнаруживаются 
в ходе модульного тестирования, проблемы сквозной работы (еп -о- 


і ; статические и структурные: тесты являются а точными Грубые оаге- 
‚втатеа) тесты предост: б обще 


5 плуатации. являются АА 


Енг Нгуен (Нипр Мелуеп) в книге " Тазійте Аррёсайот оп йе МР говорит о тестировании 
методами “серого ящика”, под которыми он понимает тестирование поведения системы с 
использованием определенных знаний о ключевых технических рисках и архитектурных 
решениях для более быстрого и качественного поиска дефектов. 


Глава 6. Изучение и обсуждение содержания проекта 175 


епа регіогтапсе) приложения могут быть обнаружены только при сис- 
темном тестировании. | 

На рис. 6.8 показана У-модель, рассмотренная в главе 1, снабженная 
степенями точности тестирования, обычно сопровождающими каждый 
уровень. Когда проект следует каскадной модели, все четыре вида тести- 
рования могут применяться на протяжении большей части проекта. 


Рис. 6.8. У-модель, дополненная детализацией точности тестирования 


Позвольте завершить этот подраздел двумя замечаниями. Во-первых, 
поскольку для изучения этой темы доступно много хороших книг, выбор 
верной стратегии для проекта тестирования является больше искусст- 
вом, чем наукой. Планируйте со временем улучшить свои навыки. Если вы 
впервые готовите стратегию тестирования, поищите специалистов, кон- 
сультантов и коллег, обладающих опытом. Они помогут вам. 

Основанием для этого совета является следующее наблюдение. Неко- 
торые опытные тестировщики и тест-менеджеры успешно проводят тес- 


176 


Часть І. Планирование 


тирование, не составляя письменный план тестирования. В некоторых 
случаях эти специалисты не могут даже объяснить, почему они выполня- 
юттот или иной тест. Тем не менее эти практики могут отменно себя про- 
явить при работе с проектами, в которых не особенно внимательно отно- 
сятся к подготовке документации. Сильная стратегия тестирования сама 
по себе может компенсировать большое число других недоработок, в том 
числе и в области планирования тестирования. 


Особый случай: стратегии управления рисками 
регрессионной зависимости 


Вернемся к предпоследнему пункту на рис. 6.6. Джамал предлагает по- 
вторить ранее выполненные тесты, для того чтобы обнаружить регрес- 
сионную зависимость, или регрессию. Вообще говоря, риск регрессион- 
ной зависимости существует всегда, если в систему вносятся изменения 
хотя бы в одной строчке кода!. Этот риск возникает не только при изме- 
нении кода, но и в случае изменения аппаратной части, встроенных про- 
грамм, конфигурации, баз данных, сосуществующего программного 
обеспечения, сетей и т.п. В одном проекте по разработке Интернет- 
приложения основной источник риска регрессионной зависимости со- 
стоял в неконтролируемых изменениях, которые производил без уве- 
домления производитель встроенных программ для интегрированного 
модема. 

Риск регрессионной зависимости имеет несколько особенностей. 
Один из способов рассмотрения регрессионной зависимости состоит 
в том, чтобы работать с ней после ее обнаружения. 


и Программист или инженер производит изменения в системе, при- 
водящие к регрессионной зависимости, которая не обнаруживает- 
ся при тестировании, пока не будут внесены в систему другие изме- 
нения. Чем больше таких изменений внесено в систему, тем труднее 
изолировать причины регрессионной зависимости до вызвавшего 
проблему изменения, особенно если последующие изменения мас- 
кируют регрессионную зависимость или оказывают влияние на ее 
поведение. 


= Программист или инженер производит изменения в системе, 
‘приводящие к регрессионной зависимости, которая не обнару- 
живается при тестировании ни при каких условиях, но затем ее 
находят пользователи или заказчик. Как уже отмечалось, чем 
больше изменений внесено в систему до обнаружения пользова- 
телем регрессионной зависимости, тем труднее изолировать ее 
причину. | 


Первый вид регрессионной зависимости приводит к нежелательным 
трудностям и задержкам в процессе отладки, что также ведет к задержкам 
в тестировании. Второй вид регрессионной зависимости отрицательно 


1 Исключительный пример: это опечатка (“6” вместо “О”)) в программе для телефона 
55-7, которая привела к выходу из строя большого числа аппаратов (больше семи миллио- 
нов) в различных районах Соединенных Штатов. 
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влияет на впечатление пользователя от системы. Если какой-либо вид 
регрессионной зависимости возникает в областях, которые не подверга- 
лись тестированию из-за намеренных компромиссов между рисками каче- 
ства, сроками, бюджетом и свойствами системы, то такие регрессионные 
зависимости, как это ни печально, находятся вне пределов контроля 
группы тестирования. 

Однако если регрессионная зависимость проявляется в областях, 
проверяемых при тестировании, это происходит в результате пропус- 
ков в регрессионном тестировании. Для второго вида риска регресси- 
онной зависимости: если считать, что она имеет место в свойстве, про- 
тестированном до вызвавшего ее изменения, а не после, то ошибка 
регрессии, обнаруженная заказчиком или пользователем, также избе- 
жала тестирования. 

(В качестве отступления вспомним обсуждение экономики тестиро- 
вания в главе 4. Первый вид регрессионной зависимости увеличивает за- 
траты на внутренние несоответствия, что сокращает объем возврата 
вложений в тестирование. Второй вид регрессионной зависимости 
представляет затраты, понесенные от внешних несоответствий. Эти не- 
соответствия относятся и кгруппе тестирования, пропустившей регрес- 
сионную зависимость, и к программисту, который внес ухудшающее ра- 
боту системы изменение.) 


г равицы регресенонного он ОЕТ 
(Коргеваіов Тез бар) вання 
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Другой способ рассмотрения регрессионной зависимости охватывает 
весь жизненный цикл системы: от первоначальной концепции до списы- 
вания системы. Предположим, что мы работаем над версией системы 
Х.У, а ранее мы выпустили версии 1.0, 1.1,..., 2.0, 2.1,..., Х.0, Х.1,..., Х.(Х-1). 
Могут иметь место два вида регрессионной зависимости: 


и Программист или инженер производит изменения в системе, при- 
водящие к регрессионной зависимости возможностей или свойств 
системы, которые являются новыми для версии Х.У. 


и Программист или инженер производит изменения в системе, приво- 
дящие к регрессионной зависимости возможностей или свойств сис- 
темы, которые появились в одной из версий, предшествующих Х.У. 


Первый риск является менее проблемным. Поскольку мы говорим о 
новом свойстве, оно, вероятно, представляет какую-то потребность неко- 
торого подмножества пользователей, но, по всей видимости, не все поль- 
зователи в ней нуждаются, что означает уменьщение бизнес-риска. Более 
того, поскольку это свойство или возможность системы заказчик еще ни- 
когда не видел в продукте, бизнес-риск дополнительно снижается за счет 
того, что для этой возможности не было выработано никаких устоявших- 
ся последовательностей действий, которые должны быть пересмотрены. 
(Хотя ранее объявленные возможности и свойства, недоступные пользо- 
вателю, могли бы появиться в рамках запланированных последовательно- 
стей действий.) Наконец, поскольку разработка и тестирование версий 
сопровождения обычно сводится к работе над новыми свойствами и воз- 
можностями, технический риск таких регрессионных зависимостей и 
пропусков в регрессионном тестировании будет ниже. 

И наоборот, бизнес-риски и технические риски будут выше в следую- 
щих трех случаях. 


1. Вы часто располагаете ограниченной информацией о том, какое 
подмножество пользователей применяет определенное свойство 
или возможность системы. 


2. Любое свойство или возможность системы может легко стать не- 
отъемлемой частью последовательностей действий пользователей, 
причем в значительной мере независимо от того, какое подмноже- 
ство пользователей действительно применяют это свойство или 
возможность системы. 


3. Поскольку и программисты, и тестировщики фокусируются на 
каких-то других вопросах, можно с большой вероятностью пропус- 
тить регрессионную зависимость. 
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В таблице 6.2 собраны факторы, связанные с моментом обнаружения 
регрессии и с жизненным циклом системы, и соответствующие риски. 


Таблица 6.2. Различные сценарии проявления регрессионной зависимости 
и вероятное развитие событий 


Обнаружены при тестировании 


Обнаружены пользователем 


Новое свойство Увеличение затрат на достижение Неспособность поставить версию 


или новая желаемого качества и задержка вы- с заявленным составом свойств. За- 

возможность пуска версии системы. траты на исправление ошибок экс- 
‚ плуатации. Возможный ущерб для 

имиджа компании. 

Существующая Значительные затраты на предска- Нарушение работы частей систе- 

возможность зание и обнаружение регрессион- мы, ряд из которых является не- 

или существую- ных зависимостей. Возрастающиє отъемлемой частью последователь- 

щее свойство затраты и задержки выпуска про- ности действий пользователей. За- 


дукта с желаемым качеством. Воз- 
можные трудности при исправле- 
нии ошибок из-за текучести кад- 
ров. 


траты на исправление дефекта экс- 
плуатации, обычно в виде дорого- 
го аварийного патча. Серьезньй 
ущерб имиджу компании. Юриди- 


ческая ответственность. 


Неспособность подготовить и выполнить эффективную стратегию 
тестирования может завести работу компании в порочный круг в рамках 
четырех клеток таблицы. Ранее я работал в компании, где некоторое вре- 
мя мы добавляли очень много новых свойств в каждую версию сопровож- 
дения при недостаточном времени на тестирование и отладку. В этот 
период, до постановки под контроль процесса выпуска версий сопровож- 
дения, президент компании получил письмо от одного из заказчиков, в 
котором была такая строчка: “Я никогда не имел дел с компанией, кото- 
рая так мало заботится о качестве”. Не самая приятная ситуация, особен- 
но для тестировщика. Так это или нет, но часть обвинений в пропусках, 
допущенных при регрессионном тестировании, покончит с доверием 
группе тестирования. 

Самая известная стратегия снижения риска регрессионной зависимо- 
сти состоит в повторении тестов. Существуют разнообразные подходы к 
выбору нужных тестов и частоты, с которой эти тесты необходимо вы- 
полнять повторно. Поскольку тема выходит за рамки этой книги, я приве- 
ду несколько ссылок на другие источники. 

Поскольку автоматизированное тестирование целиком состоит из 
подготовки и настройки повторяемых тестов, любая из книг на эту тему 
должна описывать способы выбора тестов для автоматизации, а также 
предлагать решение проблемы оптимизации возможностей управления 
риском регрессионной зависимости с помощью автоматизированных 
тестов. Эту информацию можно найти у Фьюстера и Грэма в “Зойшате Теѕі 
Ашотайот” и у Дастина и др. в “Автоматизифованном вор про- 
граммного обеспечения”. 

Стратегии повторения тестов при ручном тестировании, а также не- 
которые ограничения автоматизированного регрессионного тестирова- 
ния рассматриваются в главе 3 моей книги "Мапаріпр іће Тезійпр Рүосеѕз”. 
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Если вы предпочитаете стратегии частичного, а не полного регрессион- 
ного тестированйя при ручном выполнении тестов, можно воспользо- 
ваться методами анализа рисков качества, рассмотренными в главе 2 
настоящей книги. Для отбора повторяемых тестов можно также исполь- 
зовать тренды дефектов, статус тестовых сценариев и общие результаты 
тестирования. Эти темы будут рассмотрены позднее. 

Мне известны еще два варианта, позволяющих снизить эти риски без 
проведения полного или частичного перетестирования. Первый вари- 
ант — это аналитический метод. У одного из моих клиентов полное мно- 
жество тестовых сценариев для комплексного и системного тестирова- 
ния требовало 20 человеко-лет для однократного выполнения, однако он 
не располагал ни временем, ни бюджетом, позволяющим повторить и 5% 
всех тестов. (Эти 5% покрывали лишь основные функции, но не неверо- 
ятные сложные последовательности действий.) Попытка покрыть все 
эти различные сценарии была бы бесполезной. 

Он использовал измерения покрытия кода для того, чтобы не оста- 
лись непроверенными большие разделы основной части исходного кода. 
Ему удалось добиться в среднем 75%-го покрытия всей функционально- 
сти при четырехнедельном цикле регрессионного тестирования, что, как 
показал опыт, существенно снижало риск регрессионной зависимости до 
приемлемого уровня. Существуют и другие аналитические подходы, 
включающие в себя анализ сделанных изменений и их влияния на систе- 
му, но я слышал от специалистов, которые пытались применять такие ме- 
тоды, что они крайне непрактичны, их следует применять к тривиаль- 
ным изменениям. 

Вторым направлением является эмпирический подход — широкое 
применение методов опытной эксплуатации. Большая программа бета- 
тестирования, например, при правильном выборе пользователей, дает 


‘хорошее пересечение различных сценариев использования системы и 


типов данных, которые имеют существенное значение для пользовате- 
лей. (Уровень качества системы в этом случае должен подходить в первую 
очередь для бета-тестирования, иначе вы рискуете охладить желание 
настоящих и потенциальных пользователей участвовать в бета-тестиро- 
вании.) Например, проблемы регрессионной зависимости, связанные 
с встроенными программами модема, о которых говорилось выше, были 
обнаружены в ходе бета-тестирования. | 

Опытная эксплуатация не исключает вероятности того, что часть 
ошибок будет пропущена. С одной стороны, в отличие от стратегии по- 
вторения тестов с известным покрытием, вы не знаете наверняка, где мо- 
гут быть эти ошибки. С другой стороны, если эти ошибки не являются су- 
щественными для ваших пользователей или заказчика, вероятно, не 
стоит тратить много времени на их поиск. Конечно, применяя подход к 
тестированию на основе рисков, описанный в этой книге, я бы не стал 
разрабатывать тестовые сценарии для покрытия незаметных, несущест- 
венных рисков, а значение рисков в большой степени определяется тем, 
насколько они беспокоят пользователей. 

В заключение позвольте заметить, что некоторые продвигают объект. 
но-ориентированное программирование как средство ограничения рис- 
ка регрессионной зависимости и, следовательно, потребности в регрес- 


Глава 6. Изучение и обсуждение содержания проекта 181 


сионном тестировании. Однако в этом направлении была проделана 
определенная работа, которая показывает, что даже инкапсуляция и на- 
следование при использовании компонентов (методов, объектов и т.п.) 
‘иначе, чем ранее применяемыми методами, неустраняют риска регресси- 
онной зависимости. Поскольку невозможно с полной определенностью 
узнать, что изменение в одной части программы не повлияет на какую- 
либо другую ее часть (хотя и сильно удаленную в терминах экземпляров 
объекта или потоков данных), риск регрессионной зависимости по- 
прежнему существует . По тем же причинам интеграция коммерческих 
программ или любых программ, разработанных третьей стороной, все- 
гда страдает от тех же рисков регрессионной зависимости. 


Определение ресурсов среды для проведения тестирования 


Наряду с выполнением полного набора тестов вопрос о том, сколько раз 
выполнять каждый тест, оказывает существенное влияние на потребно- 
сти в ресурсах тестирования. Позвольте пока оставить за рамками рас- 
смотрения вопрос о персонале, исследуемый более подробно в главе 8. 
Сейчас обратимся к вопросу ресурсов тестовой среды, которые необхо- 
димы для выполнения тестов. 

В элементарном случае выполнения тестов на автономной платформе, 
скажем, для программы офисной автоматизации на компьютере Масіпќоѕћ, 
нужно располагать количеством систем, равным числу одновременно вы- 
полняемых тестовых сценариев. Допустим, у вас есть 120 часов в неделю на 
тестирование. Эмпирическое правило 30 часов в неделю на тестировщика 
дает минимальную потребность в четырех компьютерах Масіпіобії в тесто- 
вой лаборатории. Однако я предпочитаю иметь по два пользовательских 
терминала любого вида на тестировщика, поскольку требуется проводить 
локализацию проблем, зависящих от конфигурации или системы. 

Предположим, что число четыре — это предельное число доступных 
рабочих станций. Если мы хотим, чтобы у каждого тестировщика было по 
два компьютера Масіпіозі, мы можем перейти на двухсменную работу, 
как это сделал Джамал в главном примере книги. При тестировании сис- 
тем на редкой аппаратной базе, например на конструкторских прототи- 
пах или огромных корпоративных универсальных машинах (ташёгате), 


для полной загрузки дорогого оборудования двухсменная работа часто` 


просто необходима. 

Если посмотреть на таблицу “Отслеживание выполнения тестов 
Зрееду\тиег 3.1” ("5М/ 3.1 Тез Тгаскіпр”)), а именно на планы выполне- 
ния тестовых сценариев для первой и второй смены (Тез Саѕе Зипатагу 
Ріап (15һій) и Теѕє Сазе Ѕиттагу Р1ап (25Ы)), можно увидеть, что ис- 
пользуются довольно простые расчеты на основе продолжительности 
рабочего времени и тестирования, чтобы определить число серверных 
кластеров, необходимых для тестирования”. Тесты, выполняемые сто- 


__ Более подробно см. статью Дивейн Перри (Оемаупе Реггу) и Гейл Кайзер (Сай Кешег) 
“Ођјес-Отіеміей Ртортатѕ ата Тезійпр" на сцезеег.п).пес.сот/реггу9доЦесонетие4 Вит]. 


2 Эти и другие документы можно найти в разделе "Рибіїсацйіопя" на ммли.гехБіаск- 
сопзи тр. сот. 
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ронними компаниями, конечно, не берутся в расчет. Тесты, требующие 
использования серверного кластера целиком, не учитываются, посколь- 
ку, как минимум, один серверный кластер выделен для выполнения не- 
которых других множеств тестов. Два теста, которые не требуют ис- 
пользования кластера целиком, могут разделять его ресурсы, но тест, не 
требующий ресурсов кластера целиком, должен выполняться на каком- 
либо сервере (поскольку каждый тест нуждается в сервере), либо ис- 
пользуя его целиком, либо разделяя его с другими. (Если вы все еще не 
поняли идею, предположите, что вы моете руки. Вы можете мыть левую 
руку больше, чем правую, но без правой руки вы не вымоете левую.) Фор- 
мулы в этих таблицах не имеют 100%-ной точности, но предоставляют 
осторожную, а не чрезмерную оценку потребностей в аппаратном обес- 
печении. 

В нашем примере оборудование для среды тестирования ЅрееаумМтгиег 
довольно простое, однако некоторые тестовые конфигурации могут 
включать в себя десятки серверов, соединенных с сотнями рабочих стан- 
ций в различных местах с разнообразными видами соединений, как сете- 
вых, так и коммутируемых. Для рассмотрения таких конфигураций обра- 
титесь к главам 6 и 7 моей книги “Мапартр іће Тезіїпр Ргосезз, 5есопа Еаййоп", 
где приводится база данных для планирования и управления сложными 
тестовыми конфигурациями. 

При тестировании сетевых систем, систем клиент-сервер, систем 
на основе браузеров, систем для универсальных машин и им подобных 
может, а в некоторых случаях и должно иметь место разделение опре- 
деленных аппаратных ресурсов для одновременного выполнения тес- 
тов. Например, в одном из проектов мы применяли генераторы загруз- 
ки для семейства серверов, чтобы построить модель пользовательской 
базы в 50 000 записей, одновременно проводя ручное тестирование с 
применением этих устройств, чтобы убедиться, что мнение пользова- 
теля о системе, особенно о ее производительности и надежности, не 
ухудшится. 

Тем не менее нужно все делать осторожно. Например, обычно тести- 
рование производительности требует использования выделенной изоли- 
рованной тестовой среды, чтобы не произошло незаметного искажения 
результатов тестирования. Тестирование обработки ошибок и восстанов- 
ления после сбоев, нагрузочное тестирование и тестирование перегрузок 
могут породить проблемы среды, которые будут проявляться при выпол- 
нении в системе любого другого теста. Даже если такие проблемы можно 
предвидеть, влияние медленной реакции и зависаний системы на произ- 
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водительность тестировщика и, следовательно, на ход тестирования 
должно бьть сопоставлено со стоимостью дополнительного оборудова- 
ния, с использованием нескольких рабочих смен, с выполнением наибо- 
лее тяжелых тестов в ночное время и др. 

. Другая сложность возникает, когда версии сопровождения, аварий- 
ные патчи и другие линии продуктов должны проверяться силами той же 
группы тестирования в той же тестовой лаборатории. В этом случае либо 
вы вынуждены иметь достаточно оборудования для раздельной поддерж- 
ки всех необходимых конфигураций, либо нужно убедить руководство рас- 
ставить приоритеты, если два или более проекта конкурируют за одни и 
те же ресурсы оборудования. План — это подходящее место для описания 
компромисса. 

Универсальные машины, серверы, сети хранения данных и другие по- 
добные объекты очень дороги, и обычно требуются разумные. способы их 
использования. Однако для персональных рабочих станций, по моему 
глубокому убеждению, аргументи экономии обычно не выдерживают ни- 
какой критики. 

Например, тестировщики рассказывали об ‘использовании программ 
виртуальных машин для того, чтобы запускать для тестирования две опе- 
рационные системы на одной рабочей станции одновременно. Ошибки, 
обнаруженные втакой конфигурации, вызывают сомнение. (Такие ошиб- 
ки будут не только сомнительны, но и абсолютно ненадежны, если речь 
идето производительности, надежности и других областях, в которых ос- 
новным фактором является использование ресурсов.) Как узнать, что не- 
которое сложное взаимодействие между операционными системами, 
программой виртуальных машин, системой, предназначенной для тести- 
рования, и другими сосуществующими программами, драйверами и дан- 
ными, явилось причиной сбоя? По этой причине ошибки, которые были 
обнаружены в таких искусственных тестовых конфигурациях, вероятно, 
найдут недоброжелательный отклик со стороны программистов, кото- 
рым поручат их исправление. 

В качестве более приемлемого варианта рассмотрим мультизагрузоч- 
ный диск или несколько дисков, которые можно выбрать во время загруз- 
ки компьютера. Конечно, нужна перезагрузка, но, по крайней мере, 
отсутствуют параллельно выполняемые задачи, которые могут использо- 
вать память и процессор компьютера. Однако, поскольку рабочая стан- 
ция в среднем стоит дешевле, чем человеко-неделя инженера-тестиров- 
щика, а потеря недели обычно дороже, чем персональный компьютер, 
сколько`вы готовы терпеть неэффективное использование рабочего вре- 
мени, если избегаете приобретения нового оборудования или введения 
второй смены? 


Управление системами тестов и конфигурациями 
тестовой среды 


Какие бы ресурсы вы ни развернули в тестовой среде, вам потребуется не- 
которым образом управлять этой средой. Доступные вам политика и ин- 
струменты зависят в немалой степени от технологий, с которыми прихо- 
дится работать. Для платформ с дисками ШЕ или $С$1 часть политики 
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управления конфигурацией среды может включать в себя создание и хра- 
нение эталонных образов дисков, т.е. их побитовых копий для известных 
подходящих конфигураций, которые могут быть при необходимости вос- 
становлены в тестовой среде. Для более крупных семейств серверов 
и универсальных машин существуют коммерческие средства управления 
конфигурациями, которые могут помочь вам в этом. 

Ключевым моментом здесь является знание о том, как создать конфигу- 
рации, похожие на конфигурации пользователей, и о том, что эти конфи- 
гурации можно восстановить с минимальными усилиями. При тестирова- 
нии возникают всякие неожиданности, иногда приводящие к разрушению 
конфигурации тестовой среды. Никому не нравится заниматься переуста- 
новкой недокументированной конфигурации вручную в середине тестово- 
го цикла, особенно с учетом закона Мэрфи, который гласит, что это собы- 
тие случится в ходе последнего тестового цикла за три дня до.срока сдачи 
версии или поставки системы! 

Неважно, насколько легко восстановить конфигурацию, вы будете не- 
комфортно себя чувствовать в случае, если она не восстанавливается 
с первого раза. Не всегдаудается сразу распознать испорченную тестовую 
конфигурацию, и это означает, что тестировщик может выпустить массу 
ложных отчетов о дефектах, пока не поймет, что происходит. Также не- 
обходимо убедиться, что тестирование само не нарушает тестовую среду. 
В главе 10 будут рассмотрены процедуры настройки и демонтажа тесто- 
вой среды, которые являются частью всей мозаики. 

Также нужно убедиться в том, что программисты и другие специали- 
сты не портят тестовую среду. По этой причине политика управления тес- 
товой средой должна включать в себя эффективный контроль прав и па- 
ролей доступа. Обычно в моей политике два железных правила. Первое: 
никто не должен вносить никаких изменений в тестовую среду без утвер- 
ждения их тест-менеджером или, по крайней мере, старшим инженером- 
тестировщиком. (В этот список обязательно входят группы сетевой под- 
держки и администрирования. Внесение плановых обновлений и опера- 
ции сопровождения тестовой среды должны быть отложены на время 
тестового цикла, а то и на весь период выполнения тестов из-за риска по- 
лучения бессмысленных результатов тестирования.) Второе: никто не 
имеет права заниматься отладкой или разрешать ее проведение в тесто- 
вой среде, за исключением времени, официально определенного груп- 
пой управления проектом, когда прекращено любое тестирование, на ко- 
торое может повлиять отладка, и после завершения отладки среда 
восстанавливается до известного состояния. 

Сотрудники, не входящие в группу тестирования, в том числе систем- 
ные администраторы, персонал сетевой поддержки и т.п., часто берут 
под свой контроль управление сложной тестовой средой. Это может по- 
родить проблемы, влияющие на ход работ по тестированию. Вам может 
надоесть ждать, когда человек придет и внесет исправления в среду, что- 
бы можно было возобновить тестирование, но унего до вас еще было два- 
три звонка, над ответами на которые он работает. Запустите процесс эс- 
калации проблемы для ее разрешения, чтобы не оказаться крайним в слу- 


чае, когда целый день не начинается тестирование, поскольку представи- 


тели поддержки не появляются. Как уже отмечалось в главе 5, особенно 
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осторожным надо быть в том случае, если вы полагаетесь на получение 
поддержки от незаинтересованных лиц проекта. 

Необходимо письменно зафиксировать соглашения по поводу под- 
держки, а также процессы разрешения и эскалации проблем. Чем вероят- 
нее, по вашему мнению, проблемы, тем более формализованными должны 
быть соглашения. Более того, процесс эскалации проблем должен подни- 
мать проблему на уровень общего для тестировщиков и поддержки руково- 
дителя, либо, по крайней мере, на уровень некоторой группы управления, 
которая может форсировать сотрудничество. Кроме того, сотрудники низ- 
щего звена группы тестирования должны чувствовать себя абсолютно 
уверенно при эскалации проблем. В моей практике были случаи, когда чув- 
ство тщетности обращений наверх приводило непосредственных испол- 
нителей группы тестирования к решению самостоятельно попытаться 
решить проблемы или найти обходной путь. Это скрытые снижение про- 
изводительности группы и замедление хода работ по тестированию. Долж- 
но быть всем очевидно, что такие неконтролируемые изменения сфер от- 
ветственности недопустимы и являются неприемлемыми. 

Я понимаю, что это звучит цинично, но такое случается. Не вызывайте 
злость, демонстрируя недоверие при обсуждении соглашений о поддерж- 
ке, но и не становитесь мальчиком для битья в проекте, игнорируя эту 
проблему в надежде на солидарность трудящихся. 

Наконец, убедитесь, что у вас есть план управления документами, ко- 
торые будут появляться в ходе тестирования. Самый простой способ до- 
биться этого — воспользоваться репозиторием для исходного кода или 
системой управления конфигурацией, применяемой в проекте для исход- 
ного кода системы. (В каждом проекте в настоящее время используется 
одна из таких систем, не такли?) Как только появляется какой-либо доку- 
мент, скрипт, отчет, график, таблица и т.п., после утверждения необходи- 
мо поместить его в этот репозиторий. Присвойте этому объекту версию и 
увеличивайте ее на единицу при каждом обновлении. | 

Наряду с отслеживанием объектов выберите способ, чтобы следить за 
тем, какой из объектов применялся для тестирования каких версий систе- 
мы. Например, если имеется набор тестовых сценариев, версия 6.1.2 ко- 
торого помещена в репозиторий, нужно иметь возможность открыть не- 
который документ с перечнем перекрестных ссылок, позволяющий 
узнать, что вы использовали эту версию тестовых сценариев для тестиро- 
вания версий системы, начиная с 3.1.007 и заканчивая 3.1.021. 

Может показаться, что этот способ систематизированной каталогиза- 
ции и хранения компонентов тестирования требует больших затрат вре- 
мени, особенно если вы не знакомы с принципами управления конфигу- 
рациями. Однако построение репозитория продуктов тестирования 
многократного применения, тестовых данных, документов тестирова- 
ния и других объектов очень полезно для будущего. Как раз потому, что 
ваша система — не одноразовое множество исходного кода, тесты являют- 
ся ценными объектами для будущих проверок качества системы `. 


1 Превосходное ведение управления конфигурацией, включая необходимость хранения 
артефактов тестирования, можно найти в статье Тима Кассе (Тіп Каззе) и Патрисии Макку: 
эйд (Рашісіа Медиа) “Зоймаге СопЯзигаНоп Мапазетегі бог Ргоієсі 1 сайта"; отори 
опубликована в сентябрьском 2000 г. номере журнала "Зо/їшате Онаіну Рюрсрнай і 
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Риски подпроекта тестирования | 


Мы не только должны использовать стратегии тестирования на основе 
управления рисками для предоставления наилучших информационных 
продуктов и услуг по управлению рисками качества заинтересованным 
лицам и внутренним заказчикам, мы также должны иметь стратегию 
управления рисками для самого подпроекта тестирования. Легче всего 
начать размышления на тему рисков подпроекта тестирования с вопроса 
самому себе, какие элементы должны удачно совпасть для успеха подпро- 
екта тестирования. Никакие два проекта не будут одинаковыми, поэтому 
необходимо опираться на отличительные черты, проявляющиеся в ходе 
всего подпроекта тестирования. Однако риски обычно растут в одном 
или нескольких направлениях, аналогичных направлениям проектов раз- 
работки. 


ш Свойства. Какие элементы, факторы и действия способствуют полу- 
чению надлежащей совокупности услуг управления рисками каче- 
ства и информационных продуктов? 


в Сроки. Какие элементы, факторы и действия способствуют получе- 
нию этих услуг и продуктов своевременно и в указанные сроки? 


= Бюджет. Какие элементы, факторы и действия способствуют полу- 
чению услуг и продуктов в рамках общего бюджета проекта путем, 
ведущим к положительному сальдо окупаемости вложений в тести- 
рование? 


ш Качество. Какие элементы, факторы и действия способствуют полу- 
чению услуг и продуктов группы тестирования, в целом удовлетво- 
ряющих заинтересованных лиц и внутренних заказчиков и лишь 
изредка (если есть в принципе) неудовлетворяющих их? 


Насколько высок риск, связанный с этими элементами, факторами 
и действиями, настолько успех проекта находится в зависимости от этого 
риска. 

‚Часто можно снизить риски, касающиеся только свойств и бюджета, 
за счет предварительного обсуждения. Каковы корректные рамки тести- 
рования, и-сколько за это готовы заплатить? 

Проблема свойств и бюджета проекта тестирования возникает в том 
случае, когда руководство диктует: “Вот вам небольшая недостаточная 
сумма средств, теперь идите и сделайте так, чтобы все проблемы качества. 
исчезли”. Как уже обсуждалось в главе 1, если вы ясно представляете кон- 
текст, представляете риски качества, которыми нужно управлять, и спо- 
собствуете пониманию другими людьми возможных компромиссов, мож- 
но добиться ликвидации этих нереальных ожиданий. Данные риски 
становятся вопросом компетенции руководства проекта, которое управ- 
ляет бюджетом и хочет знать, что деньги о раскодуютея врам- 
ках проекта тестирования. 

Риски качества для проектов тестирования по большей части связаны 
со способностью информировать заинтересованных лиц о результатах 
тестирования (см. главу 15.) Этот вопрос необходимо принимать в расчет 
при планировании. В основном примере книги Джамал рассылает на ут- 
верждение руководству формы отчетов и графиков. Если невозможно ут- 
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вердить предлагаемые отчеты или кажется, что люди не вникают в их 
смысл, возникает значительный риск в понимании качества проекта тес- 
тирования. Снова отметим, что ключевым моментом является коррект- 
ное ограничение ожиданий заинтересованных лиц. 

Риски сроков возникают из-за запутанных взаимосвязей подпроекта 
тестирования и проекта разработки. Простейший пример: риск сроков 
для проекта тестирования возникает по причине поздней поставки глав- 
ной системы. В одном из проектов сервер стоимостью в четверть миллио- 
на долларов застрял на таможне на две недели, поскольку никто не мог по- 
нять, как заплатить пошлину, что, естественно, отсрочило на две недели 
все тесты, запланированные к выполнению. 

Особенно неприятны риски, связанные со сроками. Можно выпро- 
сить больше денег, можно не реализовывать свойства, можно расслабить- 
ся по поводу требований к качеству, но если день потерян, он потерян 
навсегда. Притом, что тестирование страдает от сдвига сроков, соответ- 
ствующая дата окончания фазы тестирования часто не может быть сдви- 
нута. Это может привести к болезненным компромиссам на уровне проек- 
та, либо к поставке недостаточно протестированного и отлаженного 
продукта, т.е. с плохим и, вероятно, даже не полностью проверенным ка- 
чеством, либо купущению хорошего момента на рынке для продаж. Тща- 
тельное выявление рисков и управление ими, сопровождающее весь про- 
цесс тестирования, способствует предотвращению этих проблем. Еще 
помогает совместная работа с группой управления проектом над получе- 
нием реалистичного графика проекта в целом . 


Свистать всех наверх 


Применяя процессы и политики, рассмотренные в этой главе, я полагаю, 
что могу создать краткие и полезные документы, которые, в частности, 
помогают понять и обсуждать смысл тестирования в проекте. Хороший 
план тестирования — это богатая смесь очищенных данных планирова- 
ния (полученных из анализа рисков, графика, бюджета) с подробными 
процессами, хорошо продуманными политиками, разумными стратегия- 
ми и взаимными договоренностями с заинтересованными лицами. Из 
этого плана в проекте вырастает тестирование. 

Но я не пишу хорошие планы тестирования самостоятельно. Мне нужна 
помощь других сотрудников проектной группы. Перед тем как двигаться 
вперед, мы должны убедиться, что наш план высокого качества и поддержи- 
вается заинтересованными лицами. В следующей главе продолжается изуче- 
ние планирования тестирования. Мы рассмотрим опыт Джамала по привле- 
чению всех заинтересованных лиц к обсуждению плана тестирования, 
а затем попытаемся понять, как разработать наиболее качественный план. 


В главе 2 яупоминал книгу Стива Макконела "5о/їшате Ртојесі Зитліга! Сшаг, с. 93—101, в ко- 
торой обсуждается управления рисками проекта. Вот еще один случай, где ти методы могут 
быть полезными. 


ГЛАВА 7 


От предложения к утверждению: 
поиск поддержки качественных 
планов тестирования 

у заинтересованных лиц 


Н аписать план тестирования полезно, но план -- это лишь документ, 

набор слов. Эти слова оживают только тогда, когда рабочая группа 
проекта начинает действовать согласно плану. Таким образом, докумен- 
тированный план - это предложение, которое имеет смысл лишь тогда, 
когда люди приходят к решению выполнять его. Различные ключевые 
фигуры и внутри, и вне группы тестирования должны согласиться де- 
лать то, что отних требуется. Другие ключевые лица, заинтересованные 
в процессе тестирования и качестве системы, должны договориться, 
что тестирование, описанное в плане, будет соответствовать их потреб- 
ностям. Иными словами, будет ли тестирование предоставлять заинте- 
ресованным лицам информацию и услуги, которые способствовали бы 
управлению рисками качества системы? Как только договоренности 
достигнуты, вы получаете больше чем документ. Вы получаете общедос- 
тупную карту маршрута к ключевой части будущего проекта и поддержку 
специалистов. 

Необходимо выполнить серьезную работу на пути от первой черновой 
версии плана тестирования к общедоступной карте маршрута и к форми- 
рованию сообщества сторонников, чтобы заручиться поддержкой. 
В этой главе мы рассмотрим план тестирования, разработанный в преды- 
дущей главе, и пройдем оставшиеся этапы подготовки плана. Затем мы 
снова взглянем на весь процесс планирования тестирования, обратив 

‚внимание прежде всего на то, чем отличаются грамотное планирование 
тестирования и качественный план тестирования, и на некоторые суще- 
ствующие проблемы и пути внедрения усовершенствований. 
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Джамал выполняет подачу 


Утром 19 сентября Джамал пришел в офис и попал подгром и молнии, вы- 
званные “странной пользовательской средой”, о которой накануне гово- 
рид Кейт Ли. Менеджер пользовательской поддержки Косимо Неграєв и 
менеджер продукта Је‹Саіс Джайеш Депрендра уже ждали его. Ониневса- 


з МЫХ, деликатных выражениях говерили о том, что в предыдущей версии 


ТеСас Лин Цу пропустила ошибку. Первой мыслью Джамала было, что 
ошибка зависит от конфигурации среды, поэтому все утро он сначала ус- 
покаивал их, затем пытался вместе с Лин Цу воспроизвести ошибку в тес- 
товой среде и наконец продемонстрировал Джайешу и Косимо, что, хотя, 
по всей вероятности, можно воспроизвести ошибку вне особой конфигу- 
рации среды заказчика, она является довольно необычной. 

“Простите, друзья, что вам пришлось через это пройти, - сказал Джа- 
мал, — но, честно говоря, я не думаю, что можно найти все проблемы, свя- 
занные с различными конфигурациями, в нашей тестовой среде с теми 
ресурсами, которыми мы располагаем. Джайеш, может быть, мы подума- 
ем вместе над организацией тщательного бета-тестирования, которое по- 
зволит проверить большее число конфигураций среды и данных, кото- 
рых у нас нет?” 

“Хорошо, мы должны что-нибудь придумать! — воскликнул Джайеш. — 
Я не хочу прочитать в очередном обзоре продуктов фразу “Самая ужасная 
электронная таблица на рынке”, если только речь не идет о наших конку- 
рентах”. 

После этого Джамал погрузился в чтение электронной почты. Надо 
сказать, что отзывы на план тестирования потекли тонкой струйкой. 
Большинство из них были уточнениями формулировок, но Кейт Эрнан- 
дес сделала серьезное замечание. “Знаешь, может, я что-то упустила,- пи- 
сала она. — Но где в тестовой среде серверы для управления иерархиче- 
ским хранилищем?” 

“Боже мой, — подумал Джамал, — мы пропустили это на семинаре 
ЕМРА. Позвонив Кейт, он подтвердил, что в настоящий моментустройст- 
ва для управления иерархическим хранилищем в тестовой лаборатории 
отсутствуют. “А откуда их взять? — спросила Кейт. — Это первая версия, 
поддерживающая работу с иерархическими хранилищами”.. 

“Хорошо, жди новых заявок от твоего покорного слуги, — сказал Джа- 
мал, — поскольку нам придется еще кое-что прикупить. Нам нужен хотя бы 
один сервер”. 

Джамал написал Кейт: “Отличное замечание! Работаю над устранени- 


ем ошибки”. 


Затем Джамал отправил сообщения нескольким сотрудникам группы 
разработки, которые работали над поддержкой управления иерархиче- 
скими хранилищами. Все они ответили, что убеждены в незначительно- 
сти технического риска, поскольку системы управления иерархическими 
хранилищами используют проверенную технологию, в которой не будет 
ничего нового, но согласились с тем, что, по крайней мере; один сервер 
должен быть в тестовой комбинации. Далее он зашел в Интернет и выяс- 
нил цены на программы управления иерархическими хранилищами иуст- 
ройства хранения. Позвонив Кейт, Джамал рассказал про обсуждение с 
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программистами и спросил, нетли у нее каких-либо пожеланий по поводу 
конфигурации управления иерархическими хранилищами. Она ответи- 
ла, что ей известно, какие программы и устройства используют заказчи- 
ки, но ей не нравится мысль о расходовании денег на системы, позволяю- 
щие воспроизвести все такие конфигурации сред. Она предложила 
Джамалу выбрать приемлемую по деньгам конфигурацию, которая вклю- 
чала бы различные свойства, необходимые для разрабатываемых про- 
грамм. 

“Вот о чем я тебя попрошу, — сказал Джамал. — Позвони, пожалуйста, 
Джайешу и спроси, подходит ли для него этот план с учетом всего, что 
произошло сегодня утром”. | 

“Зачем? Что случилось с ]е Сас?” 

Джамал пересказал Кейт всю историю, добавив в конце: “Итак, по су- 

ществу риск состоит в том, что чем меньше конфигураций мы проверим, 
тем более вероятно проявление подобных проблем при эксплуатации”. 
° “Понимаю, но если мы говорим о сумме в $7500 и более на серверы с 
полной конфигурацией, нельзя построить много конфигураций, не про- 
бив серьезную брешь в бюджете. Как насчет того, чтобы взять только две: 
одну на базе МТ, а вторую на базе ОМГХ?” 

“Меня это устраивает”, — ответил Джамал. Он подготовил и разослал 
следующее письмо всем участникам семинара ЕМКА и участникам обсуж- 
дения плана тестирования. В список адресатов он включил также Джайе- 
ша, чтобы дать ему возможность высказать мнение по поводу проблем, ко- 
торые может вызвать минимальное число тестовых конфигураций. 


Привет всем! ; 


Проводя рецензированиє плана тестирования, Кейт Зрнандес заметила, что 
в ходе анализа рисков мь не определили ни одного сервера управления ие- 
рархическими хранилищами в тестовой среде. Обсудив с разработчиками и 
изучив ситуацию по Йнтернету, я пришел к вьводу, что технический риск 
минимален, хотя едва ли я являюсь специалистом в этой области. 


Поскольку даже серверы начального уровня для управления иерархическими 
хранилищами стоят около $7500 с учетом конфигурирования, Кейт и я пред- 
лагаем закупить две конфигурации: одну на базе МТ, а вторую на базе 
ОМІХ. 


Если у кого-то есть мнения по этому вопросу и аргументы за и против на- 
шего предложения, прошу сообщить об этом. 


С уважением, 
- Джамал 


Началось обсуждение. Люди писали электронные сообщения и захо- 
дили в офис Джамала. Обсуждение прекратилось с письмом Джона Ал- 
бертсона, вице-президента по поддержке разработок и непосредственно- 
го начальника Джамала. 


Всем! 


После полезного обсуждения, в которое внесли вклад все участники, прошу 
‘Принять к сведению, что Гарольд, Макс, Раджеш и я обсудили вопрос о 
серверах для управления иерархическими хранилицами для’ тестовой среды 
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проекта “Суматра”. Хотя Джайеш и другие верно ‘указали: на необходимость 
разнотипных тестовых конфигураций, верно и то, что мы не можем протес- 
тировать все. Мы должны здесь уравновесить конкурирующие приоритеты. Мы 
думаем, что предложение Кейт и Джамала о тестировании на двух конфигу- 
рациях позволяет удачно уравновесить бюджет и качество. Когда мы обсуж- 
дали бюджет на тестирование, Джамал включил значительную сумму на не- 
предвиденные обстоятельства. Закупка двух дополнительных серверов 
потребует израсходовать около 25% этой суммы. В качестве компенсации 
группа Джамала закроет при тестировании две популярные конфигурации 
серверов для управления иерархическими хранилищами. Это, по мнению 
старших менеджеров, является разумным балансом. Итак, мы даем указание 
Джамалу действовать в. соответствии с этим решением. 


Повторюсь, что мы благодарим всех за участие в обсуждении. На этом про- 
шу считать обсуждение вопроса закрытым и направлять любые дополнитель- 
ные комментарии вашим: непосредственным начальникам. 


Дж.А. 


Джамал не смог сдержать улыбки, прочитав это письмо: “Класс! Было 
бы здорово, если бы письмо было вмоем архиве, когдаутром я столкнулся 


с Джайешем. Это помогло бы мне избежать роли мальчика для битья по 


вопросам качества”. В пятницу 20 сентября он обновил план тестирова- 
ния и бюджет на основе предложенных изменений и разослал новые ва- 
рианты. 


Привет всем! 


Пожалуйста, рассмотрите готовую к рецензированию вторую версию плана 
тестирования, которая прикреплена к сообщению. Мы обсудим этот вариант 
во вторник на совещании. С нетерпением жду встречи с вами. 


С уважением, 


Джамал 
№ этапа Этап Выполнено? 
4. Разослать план для закрытого (автономного) рецензирова- Ы 


ния, обычно сначала сотрудникам группы тестирования, а за- 
тем на более широкое обсуждение среди заинтересованных 
лиц и участников проекта. Собрать отзывы и пересмотреть 
план, повторив этапы 1—3 по необходимости. Изучить любые 
изменения в имеющемся графике и бюджете (превышающие 
оговоренные резервы времени и планы на случай непредви- 
денных обстоятельств), полученные в результате процесса 


планирования, и получить поддержку этих изменений у руко- 
водства. 


Совещание, посвященное обсуждению плана тестирования, не было 
богато на события. Джамал тщательно разобрал план, страницу за стра- 
ницей, представив его основные фрагменты. Участники Джон, Гарольд, 
Дженни, Кейт Эрнандес, Ясухиро, Косимо, Речел, Макс, Джейм, Бобби, 
Лин Цу, Эмма и два старших программиста ели сэндвичи и задавали по 
ходу обсуждения вопросы. Несколько человек внесли полезные предло- 
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жения, которые привели к небольшим изменениям плана. В частности, 
Дженни предложила, чтобы примечания к версии (геїсазе по{ез) описы- 
вали известные ограничения и ошибки, помимо самого содержимого 
версии. 

Завершая совещание, Джамал сказал: “Итак, с учетом изменений, о ко- 
торых мы договорились сегодня, всех ли устраивает план? Нетли чего та- 
кого, что бы не имело смысла?” Он осмотрел комнату и увидел только со- 
гласно кивающих людей. 

“Неразумных требований к персоналу? Необдуманных предложений? 
Нелепых предположений?” 

В ответ только смех и согласное кивание. 

Джон сказал: “Джамал, я думаю, план отличный. Если мы сможем рабо- 
тать в соответствии с этим документом, тестирование пойдет хорошо. 
Макс, Гарольд, вы согласны?” 

“Безусловно,” — сказал Гарольд. Макс согласно кивнул. 

“Хорошо, — сказал Джон. — Совещание закончено”. 


№ этапа Этап Л Выполнено? 
5. Разослать план для открытого рецензирования. Провести со- 


вещание по итогам рецензирования с участием всех зайнтере- 
сованных лиц. Сделать все необходимые заключительные 
уточнения и удостовериться, что с учетом всех согласованных 
на совещании изменений план для подпроекта тестирования 


зафиксирован на бумаге и утвержден. 


Джамал, довольный тем, что у него есть надежный план с надежной 
поддержкой заинтересованных лиц, вернулся в свой кабинет. Он внес не- 
значительные изменения, которые обсуждались на совещании, а затем 
поместил план в репозиторий документов проекта. 


№ этапа Этап А Выполнено? 


6. Пересмотреть оценку графика и бюджета на основе новой ин- | 
формации, полученной в ходе процесса планирования, вклю- 
чая использование ресурсов. Если в результате происходит 
сдвиг сроков или увеличение бюджета за рамки резервов или 
планов на случай непредвиденных обстоятельств, эскалируй- 
те проблемы для решения на соответствующий уровень руко- 
водства. Обсуждение новых бюджета и графика может по- 
влечь повторение этапов планирования или переработку 
оценки затрат. 


7. Поместите план в библиотеку проекта или в систему управле- 
ния конфигурацией. Ведите контроль изменений документа. 


Построение грамотного процесса планирования 
тестирования 


В документах и шаблонах, которые являются хорошим дополнением к 
этой книге, можно посмотреть на план тестирования для проекта “Сумат- 


194 


Часть І. Планирование 


ра»!. Вероятно, вы согласитесь со мной, что это хороший план тестирова- 
ния. Но качественный процесс планирования позволяет группе тестиро- 
вания сделать больше, чем просто подготовить хороший документ. 


Установка четких критериев для фаз 


В главе 1 я объявил о своем нейтралитете или, по крайней мере, открыто- 
сти по вопросу жизненных циклов программных продуктов. Я уверен, что 
важным соображением для тестировщиков является согласование про- 
цесса тестирования с выбранными жизненными циклами и методология- 
ми. Один из путей достижения этого — выбор соответствующих критери- 
ев начала, продолжения и заверщения фаз тестирования, которые мы 
должны проводить. Если взглянуть на критерии, которые появились в до- · 
кументах проекта “Суматра”, можно обнаружить, что они выясняют со- 
стояние качества и определяют рубежи для процесса в проекте. Другими 
словами, они устанавливают стандарты, с помощью которых можно отве- 
тить “да” или “нет” на три вопроса: 


= Может ли группа проекта предоставить группе тестирования все 
необходимое для начала, продолжения или завершения данной 
фазы тестирования (готовность проекта)? 


= Имеется ли у тестировщиков все необходимое, и завершили ли они 
все приготовления для начала, продолжения или завершения дан- 
ной фазь тестирования (готовность подпроекта тестирования)? 


ш Является ли качество системы достаточным для начала, продолже- 
ния или завершения данной фазы тестирования (готовность каче- 
ства системы)? 


Ответы на первые два вопроса обычно можно дать со всей определен- 
ностью. Позвольте проиллюстрировать это с помощью следующих при- 
меров. . 

Предположим, что один из критериев начала системного тестирова- 
ния состоит в том, что все свойства, запланированные для версии, реа- - 
лизованы. Предположим также, что один из критериев продолжения 
комплексного тестирования состоит том, что все тестовые версии соби- 
раются из компонентов исходного кода под контролем средств управле- 
ния конфигурацизми. Пусть еще один критерий начала комплексного 
тестирования состоит в том, что установлена система управления де- 
фектами. Пусть критерием завершения системного тестирования явля- 
ется то, что все запланированные тесты выполнены. Все эти критерии 
могут быть либо выполнены, либо не выполнены. Это примеры, кото- 
рые неприменимы ко всем моделям жизненного цикла, но применимы к 
некоторым из них. Квалифицированные и опытные специалисты-тести- 
ровщики, понимающие динамику контекста жизненного цикла проекта, 
могут внимательно отобрать подходящие и однозначные критерии го- 
товности проекта в целом и подпроекта тестирования в частности. 


1 Этот и другие сопроводительные документы можно найти в разделе “Публикации” 
(Рибісаціопз) на ууу.техХЫасксопѕшіпе.сот. 
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Даже при тщательных размышлениях и четком понимании выбран- 
ной модели жизненного цикла выработка точных критериев готовно- 
сти качества системы остается ненадежной. Как узнать, что система 
достаточно хороша, чтобы можно было начать, продолжить или объя- 
вить завершенной фазу тестирования? Это трудные решения, требую- 
щие размышлений и проницательности. Тщательно документирован- 
ные критерии могут способствовать этим размышлениям. В случае 
начала или продолжения тестирования я обычно описываю готов- 
ность качества (для начала и продолжения, а не заверщения тестирова- 
ния) с точки зрения возможности эффективного и качественного вы- 
полнения тестов. 

„Легко сказать, что система не готова к тестированию в экстремаль- 
ных условиях. Я видел системы, которые зависали каждые 15 минут, 
и требовались длительная перезагрузка и переконфигурирование. Тес- 
тирование двигалось со скоростью улитки, если двигалось вообще, и по- 
зволяло узнать о качестве системы очень немного. Я тестировал систе- 
мы, в которых из-за большого числа серьезных ошибок не работали 
многие функции, в результате большинство тестовых сценариев невоз- 
можно было довести до завершения. Дальнейшее тестирование не дава- 
ло никакой полезной информации, поскольку система блокировала лю- 
бые попытки движения. Я работал в проектах, в которых инженеры 
сборок не могли собрать систему в течение нескольких дней. Группа 
сборки версий могла предоставить систему, которой (и исправлениям 
ошибок в ней) было уже несколько недель. Мы не могли получить ника- 
кой значимой информации о текущем состоянии системы с помощью 
тестирования такой старой версии. 

Помимо этих серьезных препятствий, становится менее ясным во- 
прос о качестве. Если мы можем тестировать, но лишь наполовину, озна- 
чает ли это, что мы слишком агрессивно планировали или что система 
столь плоха, что нужно приостановить тестирование? Верно ли, что чис- 
ло ошибок, которые нуждаются в исправлении (о которых написаны от- 
четы и принято решение об исправлении), настольно велико, что даль- 
нейшее тестирование лишь увеличит непонимание состояния системы и 
уменыпит возможности группы тестирования определять, какие ошибки 
нуждаются в исправлении? В нашем примере я выбрал число 50, так как, 
судя по моему опыту, более 50 открытых ошибок нельзя обсудить в ходе 
часового совещания по определению очередности исправления. дефек- 
тов. А с любого совещания продолжительностью более часа, участники 
обычно начинают уходить. Тем не менее, различия в контексте проекта 
могут повлиять на это число. Например, если на совещаниях дефекты об- 
суждаются подробно, то, вероятно, подходящим числом является 20. 

Еще сложнее дать ответ на вопрос, касающийся завершения опреде- 
ленной фазы тестирования. Как мы можем узнать, что обнаружили доста- 
точно дефектов в ходе тестирования (и, надеюсь, исправили их) и что 
объем проведенного тестирования достаточен? Я встречал людей, кото- 
рые пытались численно решить этот вопрос. К. примеру, я видел такие 
критерии завершения системного тестирования: 


1. Ни одной ошибки серьезности 1, менее 25 ошибок сереевности 2 
и менее 50 ошибок серьезности 3. 
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2. Не более 10% тестовых сценариев, не завершенных успешно. 


3. 90%-ное покрытие ветвей и условий в ходе всей фазы системного 
тестирования’. 


Считаю эти критерии хорошими в теории, но слабыми на практике. 
Можно вспомнить множество несущественных аргументов программи- 
стов и менеджеров по поводу классификации определенных отчетов о де- 
фектах как ошибок серьезности 1 или 2. Комбинируя тестовые сценарии 
и манипулируя их числом, обычно нетрудно сделать количество успешно 
и неуспешно завершенных тестовых сценариев таким, каким нужно. А по- 
скольку тесты в основном проходят большинство ветвей решений, озна- 
чает ли это, что мы проверили интересные условия, изучили важные по- 
токи данных и сравнили полученные результаты с ожидаемыми? 

По этой причине я предпочитаю использовать виды критериев, пока- 
занные в планах тестирования Суматры. Применяя мой подход, тест- 
менеджер или ведущий тестировщик собирает информацию и измерения 
тестирования, которые дают возможность готовить значимые отчеты 
о качестве проверяемой системы, о ходе проекта тестирования, о реак- 
ции группы разработки на обнаруженные проблемы и о мнении о тести- 
ровании в целом. Эту информацию следует представить в удобной форме 
и передать группе управления проектом (см. главу 15.) Затем группа 
управления проектом должна уравновесить риски качества, о которых го- 
ворится в предоставленных отчетах, с рисками бюджета, сроков и, веро- 
ятно, свойств системы. 

Уравновешивание рисков применимо не только к критериям, относя- 
щимся к качеству. Группы управления проектами могут отказываться и 
действительно отказываются от критериев готовности проекта и подпро- 
екта тестирования иногда по вполне объяснимым причинам, связанным с 
бизнесом. В некоторых случаях, однако, уравновешивание рисков не яв- 
ляется верным, и необходимо использовать критерии качества, измеряе- 
мые численно. Примером такого случая является поставка продуктов, 
чувствительных к безопасности, а также продуктов, критерии тестирова- 
ния которых фиксируются в контракте. В этих случаях тест-менеджер 
должен принять соответствующие критерии на основе имеющихся огра- 
ничений. 


Достижение консенсуса, согласование ожиданий, 
получение одобрения 


В большинстве моих проектов наиболее важной частью процесса плани- 
рования тестирования было не создание документа, а достижение кон- 
сенсуса, согласование ожиданий и получение одобрения, связанные с до- 
кументом. Мой подход к планированию предполагает участие всех 
заинтересованных лиц. Они получают возможность заблаговременно уз- 
нать, что именно я собираюсь тестировать, а что не буду тестировать. 
О какой помощи я намереваюсь их попросить. Как группа тестирования 


ь Обсуждение различных методов структурного покрытия, а также критериев начала и за- 
вершения тестирования єсть у Бориса Бейзера в “Зойиате Тейт Тесітідиєх. 
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будет взаимодействовать с их группой. Как, по моему мнению, мы будем 
действовать в случае непредвиденных ситуаций. Более того, они не толь 
ко узнают о том, что я предлагаю, они также могут ее в обсужде- 
нии этих предложений. 

Процесс, который я применяю для подготовки планов тестирования, 
в настоящий момент достигает кульминации при подходе, основанном на 
участии всех заинтересованных сторон и поиске консенсуса. Данный под- 
ход я использую в ходе всей части “Этап 1. Планирование” процесса тес- 
тирования, описываемого в главе 1. Джамал выстраивал консенсус по по- 
воду контекста тестирования в главе 1, по поводу критических рисков 
качества — в главе 2, по поводу определения перечня задач, оценок затрат 
времени и ресурсов -— в главах 3 —5, и, наконец, в главах 6 и 7 он ищет кон- 
сенсус по поводу плана. Другими словами, документирование плана — это 
заключительный этап в достижении того, что каждое заинтересованное 
лицо в подпроекте тестирования знает, что вы намерены делать, и что 
все ключевые игроки знают свои роли и сферы ответственности. 

Однажды за чашкой кофе я услышал от коллеги следующее остроумное 
высказывание: "Я - менеджер. Моя задача -- не допустить интересных со- 
бытий”. Можно сказать, что целью планирования является следующее: 
предотвратить неприятные сюрпризы, вызывающие панические на- 
строения. Такие сюрпризы случаются, если мы не смогли предвидеть 
сложные взаимосвязи и допущения, касающиеся того, что мы собирались 
сделать. Такие сюрпризы случаются, когда мы просим других о поддерж- 
ке, которую они не готовы оказать. Такие сюрпризы случаются, когда мы 
докладываем о необоснованных, необъяснимых результатах тестирова- 
ния или делаем это несвоевременно. В плане тестирования мы сначала 
указываем на неизвестные или скрытые детали и согласовываем предло- 
жения о том, как мы будем противостоять им. Квалифицированный тест- 
менеджер или инженер-тестировщик при создании плана представляет 
аудиторию, что люди хотят знать, что они уже знают, и как взаимодейст- 
вовать с ними с помощью документа. 

Другой аспект, связанный с аудиторией, касается того, где дислоци- 
руются потенциальные предметы дискуссии. План тестирования дол- 
жен четко показывать возможные области расхождения во мнениях. 
Если это возможно, предложите решение, которое, по вашему мнению, 
устроило бы все стороны. Если вы не уверены, что у вас есть такое реше- 
ние, или ожидаете, что участники обсуждения ввяжутся в полемику, 
можно использовать процесс планирования тестирования для содейст- 
вия обсуждению. В главном примере Джамал привлекает всю группу 
проекта к выработке подходящего уровня покрытия конфигураций. 
Если бы Джамал просто написал, что надо протестировать только два 
сервера для управления иерархическими хранилищами, тогда он рас- 
сматривался бы как автор этого решения и отвечал бы за его последст- 
вия. Вместо этого он спровоцировал дискуссию о выравнивании рисков 
на уровне управления проектом и затем “позволил” своим менеджерам 
принять решение. 

Джамал организовал и обсуждение, и решение вопроса с помощью 
электронной почты. Я тоже проводил такие обсуждения в рамках черно- 
вого варианта плана тестирования. Например, Джамал мог бы включить 
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енопозже): нам нужно реши 


б яуправления иерархическими хранилищами вкл 
вую среду. Мы с Кейт Эрнандес предлагаем два: один на базе МТ, в 1 


оборудования на бюджет с потребностью протестировать ь различные вари: 
анты ря ое и хранилищами. Джайеш, 


следующий абзац в план тестирования, непосредственно в раздел, где оп- 
ределяется тестовая среда. 

Такой подход полезен, если есть время подготовить итоговый план на 
основе нескольких черновиков. Этот процесс имеет обыкновение затяги- 
ваться, и вам приходится действовать в качестве центра, сопрягающего 
все последующие обсуждения. Например, устраивать обсуждение один на 
один, хотя, возможно, более эффективно собрать все открытые пробле- 
мы и разослать их всем за один раз, а не распространять десятки элек- 
тронных сообщений всем участникам процесса, задавая каждому касаю- 
щиеся его вопросы . 

Один из аспектов, касающихся подхода к выработке критериев, как 
было показано ранее, связан с тем, что группа управления проектом долж- 
на подтвердить свою поддержку предлагаемого подхода. Фиксируя крите- 
рии, мы договариваемся с группой, что все мы будем совместно готовить 
решение о том, что движение по фазам проекта будет осуществляться 
с учетом того, что группа тестирования может предоставить информа- 
цию, необходимую для оценки рисков качества. Другими словами, тести- 
ровщики согласны предоставить определенный перечень услуг, а проект- 
ная группа совместно принимает на себя ответственность за принятие 
конкретных решений. 

На уровне коллег существует другая форма соглашения с ответствен- 
ными за основные процессы. Например, в проекте “Суматра” Ясухиро и 


Пример плана тестирования с отметками ТВР (будет определено позже) приведен в шаб- 
лонах к книге "Мапаріпе іће Теѕйпр Ргосеѕѕ, Зесопа Кайіот", на међ-сайте угли гехаск- 
сопзиїцав.сога, Рецензент этой книги, тест-менеджер компании Масготе а Ребекка Сов- 
зда (Кефесса Ѕомада), упомянула один из методов, на который стоит обратить внимание. 
Она пишет: “Мы делаем что-то похожее [с использованием ТВОРІ, за исключением того, что 
наши планы тестирования готовятся в формате НТМІ, и публикуются на интранет-сайте 
проекта. Поскольку у нас ведется контроль изменений любого документа на сайте, каждый 
имеет доступ к редактированию этого документа. Я просто создаю в плане раздел “Коммен- 
тарии”, где сотрудники могут задавать вопросы по ходу рецензирования плана. Позднее до- 
вольно просто привести план в порядок и установить ссылки на комментарии, относящиеся 
к конкретному уточнению. Или просто добавить ответ на комментарий непосредственно 
в разделе “Комментарии”. Справедливости ради надо сказать, что я работаю с небольшой, 
дружной группой людей, которым я доверяю редактировать мой план тестирования, так что 
данный подход зарекомендовал себя хорошо. Мы по-прежнему проводим совещание, посвя- 
щенное обсуждению плана, но я считаю, что данный подход более управляем, чем дебаты с 
помощью электронной почты. Кроме того, это позволяет избежать обвинений, что я кого- 
то забыла включить в список рассылки”. 
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Джамал договорились о том, как будут поступать на тестирование тесто- 
вые версии. Кейт Ли и Джамал договорились о том, как будет происхо- 
дить поддержка тестовой среды. Дженни и Джамал договорились о пере- 
даче отчетов о дефектах. Договоренности и соглашения достигаются 
в ходе процесса планирования и документально фиксируются в плане тес- 
тирования. 

Формализация договоренностей и соглашений происходит различны- 
ми путями. В некоторых случаях может хватить просто разговора и доку- 
ментирования его результатов на бумаге. В других случаях это достигает- 
ся только в результате участия в совещании всех заинтересованных лиц 
и ключевых участников проекта. 

В некоторых проектах более формализованный процесс приводит 
к подписанию документов заинтересованными лицами и ключевыми уча- 
стниками, это означает, что они ознакомлены с планом, понимают его 
смысл и будут участвовать в его осуществлении. Решение о том, какой 
путь применять, целиком зависит от контекста. Выбирайте подход, наи- 
более подходящий для компании и проекта. 


Проведение планирования в разумное время 


Когда наступает подходящее время для планирования? Чтобы ответить 
на этот вопрос, позвольте вернуться к процессу тестирования в целом. 
Этап планирования этого процесса включает в себя создание контекста, 
но план также определяет, как будет происходить создание оставшейся 
части контекста. Процесс планирования происходит тогда, когда я об- 
рисовываю в общих чертах необходимые мне тестовые сценарии, дан- 
ные и инструменты, а также способы разработки и применения этих 
объектов. Процесс планирования происходит также тогда, когда я раз- 
рабатываю необходимые варианты тестовой среды и способы конфигу- 
рирования и поддержки этих вариантов. Некоторые из объектов и вари- 
антов среды требуют существенных затрат. На получение или создание 
других нужно много времени. Третьи требуют, чтобы для их разработки 
или использования были наняты дополнительные сотрудники. Четвер- 
тые оказывают влияние на внешние по отношению к проекту группы лю- 
дей из-за дороговизны, длительности или выхода за пределы их нынеш- 
них возможностей. О таких работах проектная группа должна быть 
предупреждена как можно раньше, что означает раннее осуществление 
планирования. 

Однако здесь “работает” еще одна сила: кривая обучения (Іеагпіпе 
сигуе). Чем раньше я начинаю планирование, тем меньше я знаю о том, 
как будут происходить события, какие стратегии будут наиболее эффек- 
тивными для тестирования данной системы, от каких видов дефектов 
будет страдать система и какую архитектуру и какие функции системы 
мы на самом деле реализуем. Это означает, что я должен планировать 
поздно. 

В статье, размещенной на меБ-сайте уму.5іскутіпаѕ.сот, посвящен- 
ном тестированию и качеству программных продуктов, Джеймс Бах 
(Јатпеѕ Васі), обсуждая планирование, проводит аналогию между плани- 
рованием и игрой в американский футбол. Ли Копленд (Іее Сореїапа) на- 
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писал статью, в которой он расширил эту аналогию. В футболе тренеры 
и защитники выкрикивают варианты игры, часто взятые из книжечек 
с вариантами, но они также должны думать самостоятельно, на основе 
развивающихся событий. 

Однако, продолжая аналогию, игра в американский футбол больше, 
чем обычная беготня 22 человек по полю с надутым кожаным эллипсои- 
дом. Например, огромные усилия необходимы для поддержания травяно- 
го покрова на полях. Требуются годы, чтобы построить стадион. Даже 
для бейсбола, кроме ромба, находящегося на открытом пространстве, 
требуется запланировать приобретение баз, одной-двух бит, нескольких 
мячей, перчаток, рулетки и т.п. Для соревнований нужны две команды, и 
если мы собираемся посмотреть хорошую игру, участники команд долж- 
ны обладать соответствующими умениями и навыками. Если нам нужны 
зрители, придется обзавестись трибунами. 

Проект тестирования, как и любой проект, тоже имеет общие черты. 
Некоторые активности проекта требуют принятия по ходу самостоятель- 
ных решений, другие — координации действий, времени для получения 
или подготовки, финансовых затрат (требуется время для получения де- 
нег) и привлечения людей (которых необходимо найти, собрать вместе и 
обучить). Планирование должно учесть все эти долгосрочные задачи и за- 
вершиться достаточно рано, чтобы можно было своевременно произве- 
сти необходимые для качественного тестирования действия. 


Разумная гибкость и творчество 


Необходимость раннего планирования неотрицает замечаний Баха и Ко- 
пленда. Качественное планирование и качественный процесс планирова- 
ния должны быть гибкими и оставлять место для творчества. Это, в част- 
ности, предоставляет квалифицированным инженерам-тестировщикам 
стратегическое направление верхнего уровня детализации, что затем по- 
зволяет им проектировать и разрабатывать нужные тесты с заранее опре- 
деленными параметрами. В нашем примере Джамал сообщит инженерам- 
тестировщикам Лин Цу, Эмме и тому, кто займет вакантную должность, 
когда, по его мнению, они должны применять ручное, а когда автоматизи- 
рованное тестирование, когда они должны использовать структурный 
подход, а когда подход на основе поведения системы, и так далее. Однако 
существует большая степень самостоятельности, допускающая творчест- 
во при проектировании тестов. 

Процесс выполнения тестов, предложенный Джамалом, более огра- 
ничен. Младшие тестировщики прослушают учебный курс, на котором 
им расскажут о процедурах выполнения различных видов тестов, о том, 
как сообщать о результатах тестирования и как писать отчеты о дефек- 


Статья Джеймса Баха называется “Исследовательское тестирование и миф планирова- 
ния» ("Ехріогагогу ТезИпз апа "Фе Ріаппіп; Муф»)), а статья Ли Копленда называется “Ис- 
следовательское планирование» ("Ехріогагогу РІаппіпр»)). Оба автора обсуждают планиро- 
вание именно в контексте исследовательского тестирования, но те же принципы 
применимы в случае, если используются скрипты для ручного тестирования или автомати- 
зированное тестирование. Ли Копленд также рассматривает исследовательское тестирова- 
ние и планирование тестирования в “ Маѕіегіпр бойшате Тез Дезірт". 
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тах. Поскольку младшие тестировщики менее квалифицированны, чем 
инженеры-тестировщики, Джамал ограничивает их деятельность. Если, 
однако, вы работаете с группой, полностью укомплектованной квалифи- 
цированными инженерами-тестировщиками, вы можете оставить зна- 
чительно больше места для трактовок и импровизации. 

Я тоже планирую с учетом гибкости. Хорошие планы должны гнуть- 
ся, но не ломаться под давлением проекта. Предположим, что вы плани- 
руете тестирование при недостаточных разделяемых аппаратных ресур- 
сах, например с применением корпоративной универсальной машины 
(пааїпбтате). Если запланировать только один цикл тестирования для 
обнаружения дефектов, которые подлежат обязательному исправле- 
нию, у вас не будет плана для перетестирования очередной тестовой 
версии с исправлениями дефектов. Аналогично, если запланировать на- 
значения в проекты очень плотно, перемещение людей из проекта 
в проект без резерва времени между проектами, то, что произойдет, 
если потребуется кого-нибудь задержать на денек в проекте? 

Способ рассуждений “а что, если” является частью создания гибкого 
плана. Встраивание резервов на эти “а что, если”, по крайней мере, кото- 
рые я могу предположить, и есть способ добавления гибкости в план. 
В главном примере книги Джамал перечисляет риски, непредвиденные 
обстоятельства и способы их смягчения на трех страницах. Это может 
быть слишком для вашего проекта, но Джамал планирует предприятие, 
стоимость которого превышает три четверти миллиона долларов, а за- 
траты ресурсов больше трех с половиной человеко-года. В этих условиях 
должна быть проявлена достаточная осторожность. 

Я применяю резервирование (времени и финансов) для обеспечения 
гибкости для тех “а что, если”, по которым я не могу сделать предположе- 
ний. В нашем примере Джамал определил 10%-ный резерв в бюджете и за- 
планировал 50%-ное увеличение объема выполнения тестов. Он также за- 
планировал исследовательское тестирование, поскольку ему известно, 
что Лин Цу, Эмма и новый инженер-тестировщик не в состоянии проду- 
мать все тесты заранее. Кроме того, Джамал зарезервировал время и яв- 
ным образом запланировал изменение существующих тестов и создание 
новых в ходе проведения тестирования. 

Хороший план должен способствовать гибкости его применения. На- 
пример, мы говорили ранее о необходимости определения в плане чет- 
ких критериев начала, продолжения и завершения различных фаз тести- 
рования. Однако было также отмечено, что эти критерии определяют 
в основном методы и моменты времени для проверки рисков качества по 
отношению к проекту. Рабочая группа проекта должна соотнести эти рис- 
ки с бюджетом, сроками и свойствами системы и вполне может принять 
решение временно отказаться от каких-то критериев. Как вы поступите, 
когда это произойдет? Вы, по всей видимости, не сможете работать столь 
же производительно и эффективно, как раньше. Если не предусмотреть 
заранее таких ситуаций, вам придется принимать решение на ходу. Хотя 
это также может сработать, степень гибкости не будет такой, как если бы 
эта ситуация была заранее предусмотрена. 

Например, в одном из проектов я запланировал провести нагрузоч- 
ное тестирование для интеграции некоторых подсистем с помощью ав- 
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томатизированных инструментов. Однако инструменты не были вполне 
готовы, когда наступило время для выполнения нагрузочных тестов. 
Группа управления проектом временно приостановила критерий нача- 
ла тестирования, определенный как «готовность инструментов тести- 
рования». Мне пришлось импровизировать, что я и делал, тестируя па- 
раллельные потоки данных относительно интерфейсов с привлечением 
большой группы (примерно 50 человек) младших тестировщиков. По- 
скольку я не планировал такого мероприятия, нам пришлось обратиться 
в относительно дорогое агентство по найму временных сотрудников, 
причем некоторые из них не имели достаточной квалификации. Допол- 
нительная проблема состояла в том, что практически не было времени 
на обучение, поэтому они сделали много ошибок, которые потом легли 
тяжким бременем на инженеров-тестировщиков. Еще одно неудобство 
из-за отсутствия у младших тестировщиков опыта тестирования вырази- 
лось в необходимости написания подробных тестовых скриптов, кото- 
рые с учетом ограничений во времени потребовали от инженеров- 
тестировщиков потратить все выходные на подготовку скриптов при ра- 
боте по 12 часов в день. Поскольку эти тесты писались в пожарном по- 
рядке и в неудобное время, мы сделали массу промахов, включая отчеты 
о псевдоошибках и пропуск ошибок. Я бы мог смягчить эти проблемы, 
если бы учел их при планировании. 

Конечно, существуют разумные пределы гибкости и творчества. Если 
попытаться учесть в плане все возможные проблемы, можно обнаружить 
то, о чем как-то писал Томас Джефферсон (Тһотаѕ ЈеЌегѕоп): “Сколько 
боли нам причинили несчастья, которых никогда не было!”! Можете ли 
вы позволить себе полное дублирующее множество конфигураций тесто- 
вой среды в другом месте, соединенное с другой магистралью Интернета, 
лишь на случай попадания метеорита или бомбы в тестовую лаборато- 
рию? В некоторых случаях это, может, и нужно, но мне никогда не прихо- 
дилось работать в проекте, требующем такой степени гибкости. 

Творчество, естественно, тоже имеет свои пределы. Исследова- 
тельское тестирование, конечно, может и играет важную роль при тес- 
тировании многих проектов. Однако следует определить ограничения 
для тестировщиков таким образом, чтобы знать, что они тестируют и 
что они тестируют то, что нужно. Эти ограничения могут существенно 
меняться в зависимости от навыков и опыта группы тестирования, от 
необходимости позднее в точности повторять тесты, от того, насколь- 
ко подробно должны быть документированы тесты и результаты тести- 
рования ит.д. 


Подготовка надлежащей документации 


В большинстве проектов, в которых я участвовал, план тестирования не 
являлся сам по себе завершающим документом, а выступал в качестве 
средства проведения успешного проекта тестирования. Документирован- 
ный план, который готовится в ходе процесса планирования, — это суще- 


1 Изкниги Джефферсона "А Ресаюзие ої Сапоп5 ог ОБзегуаНоп іп Ргасйса! 11е”, которую 


можно найти среди его избранных работ на сайте Библиотеки Конгресса США муу Лос. б0у. 
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ственная часть обсуждения проекта тестирования с другими людьми и 
достижения документированных соглашений в сложном предприятии. 
Иногда план тестирования является самостоятельным продуктом. При 
работе с независимыми тестовыми лабораториями план тестирования 
всегда является документом, поставляемым заказчику. 

Независимо от того, на что делается упор в первую очередь: на про- 
цесс планирование или на документ под названием “план тестирова- 
ния”, — некоторые специалисты-тестировщики готовят итоговый доку- 
мент в соответствии со стандартом документирования. Например, в 
вашей компании может быть принят стандарт документов Института. 
инженеров по электротехнике и электронике (Іпѕіісиќе ої Кіесігіса! апа 
Несгоп1с Епріпеегѕ, ІЕЕЕ). В этом случае план тестирования должен со- 
ответствовать стандарту ІЕЕЕ 829. Определенные методологии разра- 
ботки и инструменты, которые автоматизируют подготовку докумен- 
тов, могут оказывать влияние и даже определять, как документируется 
план тестирования. В ряде отраслей закон предписывает определенные 
стандарты документирования, в том числе и для планов тестирования. 
Примером является, в частности, разработка программного обеспече- 
ния для атомной промышленности и медицины. 

Цели плана и процесса планирования также оказывают влияние на 
степень детализации и объем документов. Планы тестирования, написан- 
ные в соответствии с определенным стандартом, должны включать в себя 
все разделы, заданные в стандартном шаблоне. Планы тестирования, ко- 
торые готовятся для сложных случаев (сложность предметной области, 
техническая, проектная сложность или сложность тестирования), обыч- 
но требуют большей детализации и более подробного описания, чем пла- 
ны тестирования для простых случаев. Планы тестирования, подготов- 
ленные для использования группами людей, состоящими целиком из 
опытных специалистов, будут, вероятно, слишком непонятными для 
группы тестирования, составленной из людей с недостаточным опытом 
тестирования или с полным его отсутствием. 

В нашем примере ситуация, в которой оказался Джамал, подобна вто- 
рому случаю. Частично он имеет дело с определенным уровнем детализа- 
ции, необходимым для пояснений в процессе обучения и курирования 
младших сотрудников. Он также готовит точный, подробный план тести- 
рования. 

Даже если нужно писать точные и детальные планы, я остаюсь при- 
верженцем краткости. Я нехочу тратить время, силы и бумагу на описа- 
ние аспектов проекта, которые очевидны или уже согласованы. Джа- 
мал не должен объяснять понятие Интернет-протокола (ІР) в своем 
плане, поскольку он предполагает, что все, работающие над проектом, 
знают, что это такое. Он не должен объяснять, что тестировщики будут 
использовать эти ІР-адреса для доступа к Суматре через међ-сервер, по- 
скольку полагает, что все читатели плана тестирования знают, как это 
делается. (Возможно, он должен обучить этому некоторых неопытных 
младших тестировщиков.) Хороший инженер-тестировщик или тест- 
менеджер при написании плана тестирования представляет, для кого 
он пишет документ и как с его помощью взаимодействовать с этими 
людьми. 
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Я полагаю, что изобразительные средства являются хорошими заме- 
нителями текста в плане тестирования. Описание контекста, в котором 
работает группа тестирования, и архитектуры тестовой среды — два оче- 
видных примера, которые можно увидеть в плане тестирования для про- 
екта “Суматра”. Также с помощью образов можно описать сложные про- 
цессы. Даже при условии, что на рисование требуется больше времени 
и из-за размера картинок увеличивается общий объем документа, я счи- 
таю, что картинки помогают визуально представить, как работает систе- 
ма, и делают план тестирования более понятным. 

В некоторых проектах необходимо готовить несколько планов тес- 
тирования. Фазы тестирования, которые значительно отделены друг 
от друга по времени, могут потребовать отдельных планов, поскольку, 
вероятно, не удастся получить всю необходимую информацию сразу 
для написания единого плана. В ряде случаев существенно отличается 
аудитория читателей планов для различных видов тестирования, что 
также ведет к написанию нескольких планов. Например, я работал в 
проекте по созданию Интернет-приложения, в котором были подго- 
товлены отдельные планы для тестирования аппаратной и программ- 
ной частей. Если нужно готовить несколько планов тестирования, су- 
щественно сократить работу помогает подготовка общей части, 
например описания процесса подготовки отчетов о дефектах, которая 
включается в один из планов, а в остальных планах только приводится 
соответствующая ссылка. 

Краткость планов тестирования не означает, что работа по их под- 
готовке тривиальна. Напротив, нет ничего более тривиального, чем 
взять шаблон и заполнить его тем, что приходит в голову в соответст- 
вии с заголовками в нем, а затем отдать 100-страничный документ на 
рецензирование. Такие документы не способствуют эффективному и 
качественному тестированию, они являются вычурным орнаментом 
или безнадежным жертвоприношением богам программирования. 
Краткость означает использование одного правильного слова вместо 
сотен почти правильных слов. Говорят, что Густав Флобер, автор “Ма- 
дам Бовари”, тратил часы, мучительно подбирая каждое слово. Конеч- 
но, не следует тратить столько времени, но большое значение имеют 
ясность выражений и хороший стиль письма. Марк Твен писал: “Разли- 
чие между верным словом и почти верным словом — это различие меж- 
ду молнией и светлячком”. 


Предоставление возможности для обнаружения ошибок 


В применяемом мною процессе планирования документ проходит через 
многократные рецензии, проводимые ключевыми участниками проекта 
и основными заинтересованными лицами. Процессы рецензирования 
служат двум целям, первой из которых является достижение согласия 
и принятия обязательств. Вторая цель — это обычная цель любых обзоров 
документов: предоставить возможность для обнаружения ошибок. И ав- 
тономное рецензированиє, и обсуждение с глазу на глаз позволяют вы- 
явить пропуски и неудачные допущения до того, как они приведут к зна- 
чительным проблемам в ходе тестирования. 
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В главном примере книги Кейт Эрнандес обнаружила, что системы 
управления иерархическими хранилищами не включены в перечень тес- 
товой среды в первой версии плана тестирования. Это такая ошибка, что 
если бы Джамал не вынес план на обсуждение, то ее могли бы не обнару- 
жить до начала тестирования, а позже она бы наверняка отвлекла силы 
группы Кейта Ли на ее решение, а также потребовала бы усилий со сторо- 
ны группы тестирования на проверку конфигурации и, вероятно, вызва- 
ла бы задержку в проведении тестирования. Кроме того, если бы группа 
тестирования обнаружила ошибку в программе, связанной с серверами 
для управления иерархическими хранилищами, в конце тестирования, 
задержка в локализации ошибки могла бы оказаться пагубной для сроков 
и бюджета проекта. 

Также в примере была проиллюстрирована необходимость достиже- 
ния баланса при исправлении ошибок. Как и в случае с анализом рисков 
качества, при планировании тестирования существует тенденция рас- 
ползания рамок тестирования, когда планы подвергаются рецензирова- 
нию. Разные люди заботятся о разных рисках, как, например, Джайеш в 
нашем примере. Ничего не стоит внешнему заинтересованному лицу 
заявить: “Нужно включить мой любимый тест (или тестовую среду, или 
длину цикла, или...) в тестирование”. Но если вы управляете тестирова- 
нием, вы должны оказывать влияние на свой проект. Необходимо урав- 
новешивать даже законные требования ключевых участников проекта 
или заинтересованных лиц исправить ошибку (для снижения риска ка- 
чества) с другими рисками, возрастающими в рамках подпроекта тести- 
рования. 

Тестировщики должны уметь управлять процессами рецензирования 
независимо от того, предоставляют ли они свои материалы для рецензи- 
рования или изучают чей-либо еще документ. Журнал “Руојеѕѕіопаї Теѕіе? 
опубликовал серию статей о критических умениях и навыках тестиров- 
щика. Их авторы считают рецензирование одним изтаких умений и клас- 
сифицируют его как умение работать с людьми". Более подробно тема 
умений и навыков тестировщика будет рассмотрена в следующих двух гла- 
вах, посвященных поиску и найму персонала. В то же время для процесса 
планирования тестирования ключевым является то, как тестировщики 
применяют рецензирование, инспекции, просмотры или другие статиче- 
ские методы тестирования для поиска ошибок в написанных ими планах 
тестирования. 


Использование синергетики в планах проекта, разработки, 
сборки и интеграции 


Последнее указание на грамотный процесс заключается в том, что план 
тестирования и процесс планирования тестирования соответствуют пла- 
нам разработки, сборки, интеграции и соответствующим процессам пла- 
нирования. Под этим я подразумеваю, что процесс должен удовлетворять 
двум соображениям. 


1 сы. “Реоре 5КіШ5, аси тр Фе Кеуієм аз а Тез Тесһпідие”, Ро/г5зіота! Тезіст, Моїате 2, 
Іѕѕие 2 (Јапе 2001). 
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Первое соображение связано с объединением процессов планирова- 
ния, происходящим в компании как помимо вас, так и с вашим участием. 
В идеальном проекте производятся следующие действия: 


= Менеджер проекта или группа управления проектом создает план 
проекта. 


и Менеджер или менеджеры разработки создают планы разработки 
и интеграции компонентов. 


и Менеджер подготовки сборок или конфигурационного управления 
готовит план сборок. 


В нашем примере Джамал должен знать, когда инкременты будут гото- 
вы для комплексного и системного тестирования. Он получает эту инфор- 
мацию из плана Дженни. Информация о том, что тестировщику необхо- 
димо учесть в плане тестирования, становится доступной в ходе 
процессов планирования, используемых другими людьми, и, таким обра- 
зом, тестировщик должен встраивать свой процесс планирования в упо- 
мянутые процессы планирования. 

Необходимость согласования процессов и планов приводит ко второ- 
му соображению. В нашем примере Джамал планирует тестировать пол- 
ные системы в том виде, в каком они должны поставляться заказчикам, 
в ходе системного тестирования. Что будет, если план сборок, подготов- 
ленный Ясухиро, определяет разработку пользовательской версии в сере- 
дине системного тестирования? Тестирование, будучи в конце многих 
процессов, в том числе и описанного выше, не может игнорировать ре- 
альность. 

Многие проекты не предусматривают разработку всех четырех пла- 
нов. Я выполнял обязанности тест-менеджера в проекте, который вклю- 
чал в себя разработку шести подсистем, и менеджеры групи программи- 
стов каждой подсистемы писали планы разработки, а я должен был 
готовить план интеграции и план комплексного тестирования. Я был вы- 
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Такой. подход может ‚работать даже в а 
сильно различат от версии к версии. В стат 


и применяемый аналогично. елат еа Р оно ев | 
Семе! Маїтіх” на ммм. гехбіасксопеціїпо. сот.) Проектная группа может за- 
ыы тестирование по ‘уровню 0, по уровню 6 ИЛИ по. какому-либо. 


нужден добавлять важные детали в раздел подготовки тестовых версий 
плана тестирования, чтобы компенсировать отсутствие плана сборок. 
В этих случаях существует определенная вариативность рекомендаций и 
решений, и тестировщик, определяя процессы, которым должны следо- 
вать не подчиняющиеся ему сотрудники, не должен перестараться. Мой 
опыт показывает, что мало кто столь нежелателен в проекте, как тест- 
менеджер, который пытается устанавливать процессы для других групп, 
независимо от того, делает ли это он для блага проекта или для своего 
удобства. 

В некоторых случаях планы действительно покрывают дополнительные 
части процесса разработки, которые имеют выход на тестирование, но не 
рассматривают важные вопросы процесса тестирования. Например, мно- 
гие планы проектов не определяют процесс управления дефектами. С точ- 
ки зрения процесса тестирования, это важное упущение. Сборка версий, 
поскольку она непосредственно связана и с программированием, и стести- 
рованием в проекте, возможно, располагает планом, который ориентиро- 
ван только на одну совокупность требований. Сучетом того, что эти крити- 
ческие интерфейсы могут быть нечетко определены в одном из планов, я 
обычно определяю их в своем плане после того, как договорюсь с менедже- 
рами о работе этих процессов. Изображение диаграммы контекста, анало- 
гичной той, которая была подготовлена для проекта “Суматра”, может спо- 
собствовать улучшению понимания этих интерфейсов. 
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Решение проблем 


В ходе процесса планирования и создания качественного плана тестиро- 
вания возникает множество проблем. 


Выход за пределы шаблона 


В документах, поступающих читателю с этой книгой и имеющихся на 
моем међ-сайте, приводится шаблон плана тестирования!. Я уже говорил 
о шаблоне плана тестирования, имеющемся в стандарте ІЕЕЕ 829. Эти 
шаблоны полезны для того, чтобы удостовериться, что вы не забыли ни- 
чего важного. Однако легко попасть в ловушку, если использовать шаб- 
лон для плана тестирования так же, как форму для налоговой декларации 
или сдачи единого государственного экзамена. Шаблоны выступают 
в роли полезных напоминаний, но они не могут заменить размышлений — 
существенный элемент качественного планирования. Какой бы шаблон 
вы ни выбрали, убедитесь, что процесс не деградирует до “заполнения 
с наименьшими усилиями всех пустых мест в шаблоне”, поскольку это ред- 
ко дает в результате полезный план". 


Планирование для аутсорсинга 


В нашем примере Джамал намерен подрядить две независимые компании 
для проведения двух специальных видов тестирования в рамках определен- 
ных ограничений. Кстати говоря, в последнее время стало модно рассмат- 
ривать аутсорсинг всего тестирования. Как это повлияет на план тестирова- 
ния? Существует ряд проблем, усложняющих аутсорсинг тестирования. 
Чтобы успешно их решать, планы тестирования должны их учитывать. 
Во-первых, тестирование при аутсорсинге может легко разойтись с ре- 
альными потребностями пользователей, выйти за пределы договоренно- 
стей в случае изменений, не завершиться в срок или превысить бюджет 
обычно без каких-либо уведомлений до тех пор, пока решение проблемы не 
станет невозможным. Разработка и тестирование при аутсорсинге, основан- 
ные на сказочных сроках, скупом бюджете и неоднозначных требованиях к 
продукту, с большой вероятностью обречены на провал. План тестирования 
должен предусматривать гарантии, позволяющие удерживать группу тести- 
рования при аутсорсинге на верном пути в течение всего проекта. 
Во-вторых, любые действия по управлению рисками, включая управле- 
ние рисками качества, являются при оптимальном решении межфункцио- 
нальными. В главе 2 были показаны различные методы управления рисками 
качества. Довольно необычно, если внешняя компания проводит анализ 
рисков качества с привлечением специалистов разного профиля. Как прави- 


См. раздел "Рибіїсацопзя" на им. гехМасксопзШиИте. сот. 


Тест-менеджер Мою.сот Дебора Маккандлесс (Ређогаһ МсСапаїєз5) использовала сле- 
дующую аналогию: «Я думаю, что [шаблоны] похожи на отменный наваристый бульон для 
супа. Он предоставляет мне отличную основу, из которой я готовлю замечательное, вкусное 
блюдо». С учетом моего расположения к кулинарным сравнениям, мне кажется, что данное 
сравнение безупречно. 
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ло, лучше, если в ходе фазы планирования этим процессом руководит тест- 
менеджер, менеджер разработки или менеджер проекта той компании, ко- 
торая ведет разработку, особенно в части анализа рисков качества, а затем 
передает план субподрядчикам для проведения тестирования. 

В-третьих, менеджеры высшего звена, наблюдая за процессом сверху, 
иногда бывают дезориентированы субподрядными организациями, пред- 
лагающими недорогие рабочие руки и сертифицированные процессы ка- 
чества. Эти руководители затем принимают стратегические решения 
о значительных объемах аутсорсинга, упуская определенные критиче- 
ские детали, проявляющиеся на уровне тактики, когда линейные менед- 
жеры пытаются выполнить свою часть работы. 

С одной стороны, вложения в логистику и неизбежные задержки, не- 
обходимые для поддержки географически распределенных проектов лю- 
бого вида, являются значительными и в некоторых случаях непредсказуе- 
мыми, пока не попытаться их осуществить. С другой стороны, наличие 
у выбранного партнера-субподрядчика собственных процессов вовсе не 
означает, что компания, нанимающая партнера-субподрядчика, будет об- 
ладать этими процессами. Когда две компании пытаются работать совме- 
стно, порядок встречается с хаосом, что выливается в серьезные пробле- 
мы. Это особенно верно в том случае, когда неупорядоченная компания 
рассчитывает, что ее партнеры по аутсорсингу смогут изящно отреагиро- 
вать на ежедневные серьезные изменения в плане проекта, находясь на 
значительном удалении во времени и пространстве. 

В-четвертых, тестирование требует большого разнообразия умений 
и навыков, как это будет показано в следующих двух главах. Некоторые из 
этих навыков относятся к тестированию, и специалистами с такими на- 
выками обязана располагать любая уважающая себя компания по предос- 
тавлению услуг тестирования в рамках аутсорсинга. Другие относятся 
к знанию предметной области и базовой технологии реализации систе- 
мы. Необходимо очень тщательно выбирать партнера-субподрядчика по 
тестированию, если группам тестирования требуются хорошие знания 
предметной области и технологии. 

Таким образом, возможно и во многих случаях желательно передавать 
часть тестирования внешним компаниям в качестве дополнения к неболь- 
шой эффективной внутренней группе тестирования, которая в этом случае 
занимает лидирующее положение и обладает ключевыми умениями и навы- 
ками. Внешние группы могут использоваться в качестве дополнительных ра- 
бочих рук, когда наступает время выполнения тестов. (Это можно сделать 
также внутри компании, наняв более дешевых младших тестировщиков.) 
Внешние группы, возможно, также требуются в тех случаях, когда необходи- 
мо разобраться с реализацией тестирования в областях, где внутренней 
группе тестирования не хватает умений и навыков, особенно в тестирова- 
нии производительности и безопасности. Наконец, для гарантии успеха 
проекта важен тщательный отбор партнеров поаутсорсингу тестирования. 


Тема отбора и использования ресурсов аутсорсинга тестирования рассмотрена в гла- 
ве 10 моей книги “ Мапаріпр йе Теѕііпр Рүосеѕѕ, Ѕесопа Еайіоп". Для полноты информации я дол- 
жен упомянуть, что моя консалтинговая компания осуществляет тестирование на основе 
аутсорсинга, а также предоставляет другие услуги по консалтингу и обучению, связанные 
с тестированием. 
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Если ключевые участники проекта 
не поддерживают план тестирования 


В большинстве планов тестирования, которые я готовил, упоминаются 
ключевые действующие лица, которые не входят в группу тестирования. 
В главном примере книги используется весьма типичный состав участни- 
ков проекта: сотрудники группы системной поддержки, программисты, 
инженеры сборки и менеджеры. Группа тестирования зависима от этих 
внешних участников, как правило, по двум причинам. Во-первых, эти 
люди могут обладать полномочиями, связанными с предоставлением про- 
дукта или услуги, которая необходима тестировщикам. Во-вторых, эти 
люди могут отвечать в рамках проекта за выполнение задач, предшест- 
вующих задачам тестирования. Другими словами, зависимости существу- 
ют либо по организационным причинам, либо по причинам, связанным 
с проектом. 

В большей части случаев, как показывает мой опыт, более чем в 90% 
случаев, все ключевые участники, упомянутые в плане тестирования, 
либо сразу соглашаются с тем, что я прошу, либо мы приходим к некото- 
рому компромиссу. Иногда тем не менее возникают проблемы. Когда мы 
подходим к ситуации, которая, по моему мнению, означает существова- 
ние проблем, связанных с поддержкой, я применяю подход постепенной 
эскалации проблемы. 

Я начинаю с рассмотрения возможности, что я очень даже мог заблу- 
ждаться, делая запрос. Почему я допустил, что данный ключевой участ- 
ник должен выполнять обязанности, которые поручаются ему согласно 
моему плану? Возможно, я просто что-то перепутал. Я дважды проверяю 
мои предположения, прежде чем начать требовать от кого-либо что-то 
сделать. 

Если подтверждается, что данный участник действительно должен вы- 
полнять определенные обязанности, я пытаюсь убедить его в этом. Я об- 
ращаюсь к нему один на один. Объясняю причины возникновения моих 
потребностей, а также почему сотрудники, занятые в проекте, не могут 
мне помочь. Затем я показываю значение любой задержки или приоста- 
новки его содействия проекту. Если я вижу позитивные выводы из обсуж- 
дения — человек однозначно подтверждаст, что он окажет мне содейст- 
вие и согласен с предлагаемыми обязанностями, — я четко документирую 
это в плане тестирования. Отправляя план тестирования на рецензирова- 
ние, я включаю в список рассылки не только этого человека, но и его не- 
посредственного начальника. 

Важно проявлять гибкость в обсуждениях такого рода. Для достиже- 
ния соглашения могут потребоваться поиски компромисса или разного 
рода взаимовыгодные предложения. Допустим, что Кейт Ли не мог согла- 
ситься настроить все системы в соответствии с обсуждаемым графиком. 
В этом случае Джамал мог предложить угостить обедом и ужином Индера 
и Петру, если бы они согласились потратить выходные, чтобы подгото- 
вить системы в срок. Или же можно было согласиться отложить подготов- 
ку некоторых систем на несколько дней, при условии, что ряд основных 
систем был бы уже готов к работе. 
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Можно придумать или использовать нетрадиционные методы пере- 
говоров. Однажды в Японии я участвовал в совещании рабочей группы 
проекта, которая работала с моим заказчиком по созданию новой систе- 
мы для ноутбуков. Я представил план тестирования всей группе. Во вре- 
мя перерыва менеджер линии продуктов отозвал меня в сторонку и при- 
гласил вечером на ужин. Во время ужина, выпив пива и сакэ с огромным 
количеством суши, он сообщил мне по секрету, что производственная 
группа не сможет предоставить все примеры разработки, о которых я 
просил в плане тестирования. Покончив с рыбой и пивом, мы наброса- 
ли новый план примерного размещения прототипов разработки, кото- 
рый отвечал возможностям его группы и одновременно предоставлял 
моей группе тестирования элементы в достаточном количестве для вы- 
полнения наших обязательств, хотя и более медленно, чем планирова- 
лось первоначально. 

Если я не могу получить необходимую поддержку такими способами, 
я выхожу на следующий уровень, т.е. я эскалирую проблему отсутствия 
соглашений вверх по управляющей цепочке в направлении к общим ру- 
ководителям, будь то вице-президент или даже президент компании. 
Для успеха этого предприятия необходимо приложить все возможные 
политические и коммуникативные навыки. Если эскалация вопроса ве- 
дется неверно, это может привести к потере доверия и репутации. Пред- 
почитаю решать такого рода вопросы в непосредственном диалоге один 
на один, а не с помощью массовых рассылок электронной почты и не на 
совещании. 

Цель эскалации проблемы — убедить одного из менеджеров в необхо- 
димости поддержать вас. Однако опасайтесь пустых обещаний. Я встре- 
чал таких людей, которые под давлением соглашались что-то сделать, 
а потом прибегали к затягиванию с недобрым намерением “сравнять 
счет”. Если вы полагаете, что сможете победить в дебатах за счет распоря- 
жения руководства, которое фиксирует ваш запрос, а сотрудник, принуж- 
даемый таким образом, действительно будет решать поставленную зада- 
чу, то этот уровень эскалации проблем сработает. В противном случае 
лучше перейти на следующий уровень решения проблем. 

Последний уровень, по моему мнению, —это обращение к своєму непо- 
средственному руководителю с запросом ресурсов, необходимых для са- 
мостоятельного решения вопроса. Это тяжело, поскольку, вероятно, ни- 
кто не будет рад этому запросу, и это несопоставимо с необходимостью 
управлять выполнением новой совокупности задач. Если задача чрезмер- 
на для какой-либо другой группы, — а это почти наверняка так, поскольку 
на первом месте тот человек, которого вы уже просили об этом, — то по- 
требуется продемонстрировать, что вы испробовали все возможные ва- 
рианты заручиться его поддержкой. Также потребуется объяснить, поче- 
му существует зависимость, а это может оказаться в некоторых случаях 
трудной задачей. 

Некоторые считают процесс эскалации проблем конфронтационным 
и наносящим ущерб сплоченности команды, поэтому они молча перено- 
сят дополнительные объемы работ, сваливающиеся на группу. Не считаю 
этот подход верным. Однажды одному заказчику я помогал готовить план 
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тестирования, выстраивать процесс тестирования и разрабатывать сис- 
тему тестов, а затем передал план тест-менеджеру и ее группе. В плане тес- 
тирования я описал процесс подготовки версий, за который отвечала 
группа программирования. На деле же программисты оказались неспо- 
собны выполнить обязанности по подготовке тестовых версий. Если 
тест-менеджеру нужна была тестовая версия, ей приходилось разбирать- 
ся с этим самостоятельно. 

Вместо того чтобы работать согласно процессу, описанному мной, она 
поручила работу по сборке версий кому-то из своей группы. Это сущест- 
венно снизило производительность группы тестирования и уменьшило 
ее возможности по выполнению всех запланированных тестов в каждом 
из тестовых циклов. В результате у руководства появились различные во- 
просы к ней и возникло впечатление неэффективности группы тестиро- 
вания и неисполнительности. 

Наее месте я бы вежливо, но твердо обсудил проблему с менеджером 
программистов и менеджером проекта (который был общим начальни- 
ком менеджера программистов и тест-менеджера). Я бы выразил готов- 
ность взять на себя эту обязанность, если это необходимо, но при усло- 
вии, что либо будут уменьшены рамки тестирования, либо будет 
увеличено число сотрудников группы тестирования. Возможно, в список 
также были бы включены обучение и консультации, если бы я принял на 
себя дополнительные обязанности. 

Как уже отмечалось в главе 5, особой проблемой является наличие 
ключевых участников проекта тестирования, которые не являются заин- 
тересованными лицами проекта. Если их интересы не являются сравни- 
тельно нейтральными, а действительно направлены против успеха про- 
екта, то вы, конечно, выступаете против этого. Старайтесь избегать 
таких зависимостей. Если это невозможно, запаситесь временем для ре- 
шения этих проблем с помощью процесса эскалации либо каким-либо дру- 
гим способом на ваше усмотрение. 

Некоторые проблемы поддержки связаны с отношением к делу, дру- 
гие возникают из-за некомпетентности. В рассматриваемом примере 
Джамал тщательно определяет перечень сотрудников, чтобы выявить 
проблемы компетентности заранее. В ходе обсуждения поддержки Кейт, 
в сущности, назначил испытательный срок Индеру из-за ранее возник- 
ших проблем с его квалификацией. 

Однажды я работал в проекте, где мне не удалось конкретно опре- 
делить в плане тестирования, кто является сотрудниками группы под- 
держки. Менеджер сетевых операций выделил человека, который, 
хотя и в полной мере желал работать в качестве администратора 
ОМІХ, но знал об этом меньше, чем кто-либо в группе тестирования. 
Половину времени, когда его просили о поддержке, он демонстриро- 
вал неспособность диагностировать проблему. Вторую половину вре- 
мени он, как правило, реализовывал неверное решение, что вылива- 
лось в бесполезную трату усилий группы тестирования при работе 
с неверно конфигурированными серверами. Только компетентные 
и опытные профессионалы должны заниматься поддержкой тестовой 
среды. 
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Независимо от того, обусловлены ли проблемы отношением к делу 
или компетентностью, они могут проявиться либо на фазе планирова- 
ния, что предпочтительнее, либо позднее, во время его осуществления. 
Одной из целей планирования является распознавание и разрешение 
(или, по крайней мере, смягчение) этих проблем до начала выполнения 
тестов. 

Мой опыт показывает, что успех разрешения проблем, связанных 
с внешними ключевыми действующими лицами зависит от двух факто- 
ров. Во-первых, я использую рычаги для укрепления взаимоотношений 
с другими менеджерами и коллегами. Это важно не только для получе- 
ния поддержки, но и для понимания, насколько надежным является их 
отношение к поддержке. Что касается меня, я убежден, что доверие меж- 
ду профессионалами растет по мере того, как мы даем обещания друг 
другу и затем выполняем их. Если человек, не подводивший меня на про- 
тяжении 6-7 проектов, говорит, что он это сделает, я верю ему. В то же 
время человек, с которым я никогда не работал, должен иметь хорошие 
рекомендации. | 

Во-вторых, я не только стремлюсь занимать разумную позицию, но 
стараюсь также тщательно управлять и добиваться понимания разумно- 
сти моей позиции. Если меня станут воспринимать как истерическую лич- 
ность, преувеличивающую опасность ситуации или устраняющуюся от 
процесса, я нанесу непоправимый ущерб доверию и взаимоотношениям 
с моими коллегами. Специалист-тестировщик может быть эффективным 
только в том случае, когда другие люди прислушиваются к результатам его 
поисков и доверяют тому, что он сообщает им . 


Подчинение закону и следование правилам 


В качестве последней проблемы отметим, что в некоторых случаях план 
тестирования может случайно и весьма неприятно столкнуться с зако- 
ном, если быть невнимательным. В одном из проектов мы собирались 
тестировать сквозной процесс установки и сопровождения версии для 
программы, написанной в США, установленной на аппаратной плат- 
форме в Тайване, а затем поставленной непосредственно заказчикам 
снова в США. Было только одно препятствие: программа содержала 
в браузере технологию шифрования, которая классифицировалась со- 
гласно американским законам как средство вооружения. Экспортиро- 
вать это “средство вооружения” без разрешения Министерства торгов- 
ли является серьезным преступлением, которое наказывалось в то 
время пятью годами заключения и штрафами, связанными с признани- 
ем виновным. 

Существует множество законов, регулирующих перемещение техноло- 
гий через границы либо внутри страны. Например, некоторые европей- 
ские страны регулируют технологии шифрования и запрещают частное 


1 > - 
По общей теме поддержки со стороны ключевых действующих лиц можно также посмот- 


реть презентацию Ли Копленда (ее Сореіапа) Мех Неіріпр Юоеѕп'є НеЇїр" на 
мм. зНскупа@5.сот. 


214 


Часть [. Планирование 


владение такими программами. Перечень непристойных материалов мо- 
жет быть увеличен в некоторых странах или юрисдикциях. Настоящие за- 
коны США запрещают публикацию технологий, которые обходят опреде- 
ленные схемы предупреждения копирования, например, для ОУО. 

Существуют ситуации, когда тестировщик, пытаясь проверить про- 
дукт перед поставкой заказчикам, может непреднамеренно совершить 
серьезное преступление, способное привести к неприятным последст- 
виями для его последующей жизни и даже к окончанию карьеры. Если вас 
одолевают сомнения, проконсультируйтесь с юрисконсультом компании, 
знакомым с содержанием продукта и законами, которые регулируют вла- 
дение им, его передачу и использование. 

В некоторых случаях тестирование является также предметом регу- 
лирования властей. В США Управление по санитарному надзору за каче- 
ством пищевых продуктов и медикаментов устанавливает порядок тес- 
тирования медицинского оборудования. Стандарты Министерства 
обороны могут применяться к контрактам с Вооруженными силами 
США. Во многих других странах есть аналогичные механизмы регулиро- 
вания. Подход к тестированию должен быть признан имеющим силу, 
что часто требует подготовки документа о том, что тестирование прово- 
дится в соответствии с определенными стандартами. В некоторых слу- 
чаях необходимо утвердить документы в регулирующих органах. Если 
это так, нужно помнить, что люди, утверждающие документы, не явля- 
ются заинтересованными лицами проекта. Они стоят на страже общест- 
венных интересов, здоровья и безопасности и проводят законы в жизнь. 
Они в меньшей степени заботятся о ситуации с бюджетом и сроками 
проекта, в основном уделяя внимание выполнению своих обязанностей 
перед налогоплательщиками, законом и исполнительными органами 
правительства. 


Внедрение усовершенствований 


Что конкретно нужно сделать для улучшения процесса планирования, за- 
висит от текущего состояния этого процесса. На верхнем уровне детали- 
зации может помочь следующий подход. 


1. Понять цель процесса планирования. Зачем вам нужен план? Для 
того, чтобы написать документ? Является ли план документом для 
внутреннего или внешнего употребления? Является ли процесс 
планирования больше неформальным, чем формальным? Нужен 
ли вообще документированный план? 


2. Понять контекст тестирования, плана и процесса планирования. 
Кто является пользователем документированного плана? Какие 
лица являются заинтересованными в процессе планирования? Кто 
является ключевыми действующими лицами процесса тестирова- 
НИЯ? 


3. Если план должен быть документирован, примите решение, как 
создавать документ. Какой формат или шаблон является подходя- 
щим? Должны ли соблюдаться стандарты документирования? 
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Если нет, какую информацию необходимо собрать и зафикси- 
ровать? 


4. Начните с простого. Не надо заботиться о планировании всех воз- 
можных непредвиденных ситуаций и событий. Работайте с заинте- 
ресованными лицами для создания хорошего плана, который по- 
зволит разрешать наиболее вероятные проблемы. Не пишите 
слишком много, а сосредоточьтесь на подготовке четких и ясных 
формулировок того, что вы собираетесь делать. 


5. В процессе планирования, особенно на первых порах, ищите как 
можно больше вариантов консенсуса, по возможности при личных 
встречах. Тест-менеджер, который в одиночку готовит план тести- 
рования, а затем рассылает его как директиву, вряд ли добьется ре- 
зультата. Специалист-тестировщик, работающий непосредственно 
сзаинтересованными лицами и ключевыми участниками, подготав- 
ливая совместный и гармонично сочетающийся с контекстом про- 
цесс тестирования, с большой вероятностью разработает план ка- 
чественного подпроекта тестирования. 


Применяя этот подход для улучшения процесса планирования тести- 
рования, можно обновлять методы и стиль документирования постепен- 
но на протяжении нескольких проектов. Я разрабатывал свой подход 
к планированию тестирования и документированию планов тестирова- 
ния в течение 15 лет работы в качестве тест-менеджера проектов. Вы мо- 
жете опереться на знания, которыми я поделился с вами в последних двух 
главах, так что вам не потребуется 15 лет на обучение, однако нужно пони- 
мать, что процесс планирования должен улучшаться итеративно и посте- 
пенно. Обычно отличными возможностями для этого как на уровне про- 
екта, так и в рамках, самой группы тестирования, являются ранее 
выполненные проекты . 

Окончание этой главы также означает конец первой части книги. Мы 
рассмотрели четыре процесса, которые наметили курс науспешное про- 
ведение тестирования. Выделение времени и внимание к части процес- 
са тестирования, связанной с планированием, для запуска проекта 
тестирования в верном направлении, обычно приносит дивиденды 
позднее в ходе выполнения проекта тестирования. В моих предыдущих 
проектах многое из того, что потом шло верно — предотвращение ката- 
строф, улучшение командной работы, эффективное и производитель- 
ное тестирование, — начиналось на этапе планирования процесса тести- 
рования. Как тест-менеджер я давно верю в старую поговорку о том, что 
неудачно подготовленный план — это план неудачного проекта. 

От понимания того, что делать, мы переходим к непосредственному 
осуществлению планов. Следующий этап процесса тестирования заста- 
нет нас за подготовкой системы тестов и группы тестирования. Как и на- 
личие хорошего плана и хороших процессов, наличие надлежащим обра- 
зом подготовленных и верно выбранных людей и инструментов является 


Я благодарю Криса Денардиса (Сһгіѕ реМагаіѕ), одного из рецезентов, за упоминание 
этого факта в одном из писем. 
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критическим для успеха следующих этапов, когда мы будем выполнять 
тесты и улучшать систему, предназначенную для тестирования, и для са- 
мого тестирования. 


№ этапа Этап Выполнено? 
1. Планирование: понимание места тестирования. М 
1А Определить функциональный (система, проекты и процесс) М 
и организационный контексты, в которых выполняется тести- 
рование. 
1.В Определить и расставить приоритеты рисков качества систе- 


мы, достичь консенсуса заинтересованных сторон проекта от- 
носительно возможностей тестирования по смягчению этих 
рисков. 


І.С Оценить временные, ресурсные и финансовые затраты, необ- 
ходимые для выполнения тестирования и согласованные с 
пунктом 1.В, и получить поддержку оценки у руководства. 


Ір Запланировать задачи, зависимости и состав участников, кото- 
рые необходимы для смягчения рисков качества системы, и по- 
лучить поддержку планау ззинтересованных сторон проекта. 


Подготовка 


В о второй части книги мы изучим процессы, относящиеся кформиро- 
ванию эффективной и производительной группы тестировщиков 
и эффективной и производительной системы тестов. Так же, как у нас 
должно быть две руки, чтобы хлопать в ладоши, у нас должны быть и груп- 
па тестирования, и система тестов. Начнем с людей, поскольку именно 
инженеры-тестировщики, младшие тестировщики и другие специалисты 
по тестированию будут разрабатывать систему тестов. Затем мы рассмот- 
рим планирование, создание и сопровождение самой системы тестов. 
Как только мы разберемся в хитросплетениях создания группы тестиро- 
вания и системы тестов, мы сможем перейти к третьей части книги, где 
обсуждается выполнение тестов. 


№ этапа Этап 


Выполнено? 
2. Подготовка: собрать людей и подготовить тесты. о 
2.А Посредством найма и обучения создать команду О 
специалистов-тестировщиков, обладающих соответствующи- 
ми умениями, навыками, отношением к делу и мотивацией. 
20 Спроектировать, разработать, получить и проверить систему о 


тестов, которую группа тестирования будет применять для про- 
верки качества системы, предназначенной для тестирования. 


ГЛАВА 8 


Поиск искусных тестировщиков: 
как и кого нанимать 


М ы переходим от планирования к тем внутренним процессам, кото- 
рые существенно влияют на нашу подготовку к выполнению тес- 
тов. Для того чтобы группа тестирования могла приступить к этим про- 
цессам, она должна быть сформирована из тщательно подобранных 
индивидуальностей. Отличные группы тестирования добиваются выдаю- 
щихся достижений, а посредственные группы затевают распри с группой 
разработки и тормозят успех проекта. Выдающиеся группы тестирова- 
ния образуют вокруг хороших менеджеров, а хорошие менеджеры спо- 
собствуют развитию карьеры классных специалистов-тестировщиков в 
этих группах. 

Наличие тщательно подобранных специалистов в группе имеет боль- 
шое значение для тестирования. В самом деле, незрелые группы тестиро- 
вания со слабо поставленными процессами иногда добиваются успеха 
только потому, что была подобрана подходящая группа тестировщиков. 
Если грамотно поставлены процессы, отбор подходящих сотрудников за- 
кладывает основу успешности группы тестирования. Только команда, со- 
ставленная из квалифицированных специалистов, может добиться успе- 
ха включевых процессах тестирования, которые рассматриваются в этой 
книге. 

Процесс создания команды состоит из двух основных активностей. 
Во-первых, мы должны нанять подходящих людей, имеющих навыки, зна- 
ния и отношение к делу, которые дают им возможность выполнить рабо- 
ту. Во-вторых, с течением времени мы должны способствовать повыше- 
нию квалификации команды. Повышение квалификации должно быть 
направлено как на более качественное выполнение тех обязанностей, с 
которыми уже справляется группа, так и на подготовку к решению новых 
задач. 

Процесс создания команды существенно зависит от контекста и требу- 
ет совместных усилий. В некоторых компаниях при приеме на работу тес- 
тировщики проходят те же начальные испытания, что и программисты. 
В других компаниях специальные этапы входного контроля для кандида- 
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та, стремящегося занять вакансию, определяют отделы по работе с персо- 
налом. Обучение и другие программы повышения квалификации значи- 
тельно отличаются в разных компаниях, и в некоторых компаниях 
стандартизованы. Не пытаясь охватить весь спектр проблем управления 
персоналом, я остановлюсь на тех его элементах, которые влияют на тес- 
тирование. 

При найме на работу мы должны ответить на вопрос: “Способен ли 
этот человек помочь нам проверить качество программного продукта?” 
Этот вопрос отличается от вопросов: “Может ли этот человек писать 
код?" или “Понимает ли этот человек бизнес-задачи, которые решает сис- 
тема?”, — хотя квалифицированный тестировщик часто должен и иметь 
технические знания, и разбираться в предметной области. 

При обсуждении повышения квалификации мы должны ответить на 
вопрос: “В каком направлении развивается карьера каждого из сотрудни- 
ков группы тестирования, какие навыки необходимо иметь для движения 
по этому пути и насколько они соответствуют потребностям группы тес- 
тирования?” Такой вопрос применим и к другим группам тестирования. 
Однако в каждом конкретном случае ответ будет уникальным, поскольку 
ключевые навыки тестирования уникальны для каждого проекта. 


Процесс создания команды 


Независимо от того, как определен процесс создания команды в вашей 
компании, можно, не боясь ошибиться, предположить, что желаемым ре- 
зультатом является достижение практических договоренностей с наибо- 
лее подходящей и компетентной кандидатурой на занятие любой вакан- 
сии в компании. Эта высокая и очевидная цель часто бывает подчинена 
тактическим требованиям, в частности обеспечению соответствия трудо- 
вомузаконодательству, достижению справедливости в оплате труда и дви- 
жении по карьерной лестнице, а также соответствию местному рынку 
труда. 

Поскольку процесс создания команды управляется людьми, он может 
также быть подвержен менее рациональным, но столь же решающим фак- 
торам. Например, люди в компании, которые могут влиять на кадровые 
решения или вовлечены в принятие этих решений, часто имеют предвзя- 
тое мнение и опираются на прошлый опыт. Другим примером являются 
распоряжения по различным кадровым вопросам, которые часто появля- 
ются по прихоти руководства или как реакция на некоторые внешние со- 
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бытия или слухи. В целом, выбор коллег по работе подвержен влиянию 
тех же неуловимых психологических факторов, которые влияют на вы- 
бор друзей, супруги(а) или клубов. 

Находясь в центре этого водоворота совокупности факторов, процесс 
создания команды в большинстве средних и больших компаний опреде- 
ляется отделом по работе с персоналом. Этот процесс, возможно, похож 
на Процесс 6. В этой главе мы рассмотрим этап 1, а в следующей главе — 


этап 2. 


Процесс 6. Процесс построения команды 


№ этапа 
1. 

1А 

1.В 


1.С 


1.р 


ТЕ 


1Е 


2.А. 


2.В 


2.С 


Этап 
Нанять подходящих сотрудников группы тестирования. 


Получить разрешение на поиск кандидатов. 


объявление. 


Найти и подвергнуть испытаниям кандидатов на основе резю- 
ме, телефонных интервью; отсеять а и 
нежелательных кандидатов. 


Провести личные интервью с квалифицированными и жела- 
тельными кандидатами. 


Если есть подходящие кандидаты, сделать предложение наи- 
более успешному из них, как правило, направив ему соответст- 
вующее письмо. 


Если наиболее успешный кандидат принимает предложение, 
принять нового сотрудника на работу. Если нет, то либо по- 
вторить этапы 1.Е и 1.Е для каждого следующего по успешно- 
сти кандидата, пока успешный кандидат не примет предложе- 
ние, либо, если ни один из желательных кандидатов не при- 
нял предложение, начать процесс заново с этапа 1.А. Уведо- 
мить отвергнутых кандидатов, что они должны искать другие 
варианты. 


сотрудников группы. 

Совместно с новыми сотрудниками разработать пути разви- 
тия их карьеры. 

сотрудников и отмечать прогресс каждого. 

Активно управлять процессом овладения сотрудниками навы- 
ками, которые требуются для достижения целей как сотрудни- 
ка, так и всей группы тестирования. 


Повторить этап 1, ебли нужно найти новых людей. Непрерыв- 
но повторять этал 2. 


О 
а 


Вьшолнено? 


Определить параметры вакансии и подготовить рекламное 


Стимулировать повышение квалификации и карьерный рост 


На регулярной основе проверять пути развития карьеры всех 
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Разновидности процесса создания команды 


Только что представленный процесс является типичным для создания 
группы тестирования, однако существует много его разновидностей. Вы- 
бор варианта зависит не только от предпочтений компании и законода- 
тельства о труде, но и от размера компании, уровня сотрудника и типич- 
ного направления развития карьеры в компании. 

Например, в некоторых компаниях сотрудникам низшего звена уделя- 
ют очень мало внимания, особенно если они изначально были наняты по 
контракту или временно. Когда я поступал на работу в большой универси- 
тет программистом ОМІХ, процесс найма состоял из разговора с двумя 
профессорами о должностных обязанностях, опубликованных на доске 
объявлений в кампусе. Посовещавшись, они предложили мне работу. 
Ввод в курс дел состоял для меня в получасовой беседе с одним из диплом- 
ников этих профессоров о содержании проекта, в котором я должен был 
работать. Справедливости ради надо сказать, что позднее мой статус со- 
трудника университета рассматривался более серьезно. Я должен был 
пройти через формальный процесс, включая заполнение заявления о 
приеме, несмотря на то, что я уже давно работал там! 

Сравните это с вооруженными силами США, которые тратят огром- 
ные усилия на процессы найма, обучения и карьерного роста солдат и 
офицеров. Почему такая разница? В университете было невозможно 
представить, что в один прекрасный день я стану деканом, ректором или 
членом совета университета. Все считали, что я потрачу год-два на коди- 
рование на С и затем уйду, что и произошло. 

В профессиональной армии сегодняшний рядовой может запросто 
стать сержантом, который будет отвечать за жизни и безопасность десят- 
ков людей, сегодняшний курсант военно-морского училища может однаж- 


Глава 8. Поиск искусных тестировщиков 223 


ды стать адмиралом или командиром атомной подводной лодки, осна- 
щенной ракетами Трайдент, заняв вакансию, на которой человек может 
реально влиять на ход истории. Армия способствует исключительно внут- 
реннему карьерному росту. Таким образом, отличные решения по найму 
на низшем уровне в сочетании с непрерывной тренировкой лидерских 
качеств и других умений и навыков ведут к превосходному мастерству 
высших чинов, которые стоят на страже мира и умеют при необходимо- 
сти воевать. 

Ничего столь значительного, как судьба мира, не руководит вашими 
решениями при формировании группы тестирования, но умение окру- 
жить себя талантами определяет успех тестирования в проекте, ощуще- 
ние компетентности группы тестирования и карьерные перспективы для 
каждого тестировщика. По всей вероятности, ваши возможности по су- 
ществу влиять на этот процесс, организованный согласно приведенному 
выше описанию либо иначе, ограничены. Тем не менее в рамках опреде- 
ленного процесса создания команды вам придется принимать решения 
и выполнять действия, имеющие ключевые последствия для группы тес- 
тирования. Каквы принимаете эти решения и что вы делаете — более важ- 
но, чем сам процесс. 


Увеличение группы тестирования проекта 
“Суматра” 


Даже при составлении плана тестирования Джамал Браун занимался по- 
иском людей для группы тестирования. В соответствии с бюджетом, ут- 
вержденным его непосредственным начальником Джоном Албертсо- 
ном, Джамал мог нанять одного инженера-тестировщика на постоянную 
работу и четырех младших тестировщиков по контракту. Особенно 
срочно он хотел найти старшего инженера по автоматизированному 
тестированию, которому поручалось готовить и выполнять регрессион- 
ные тесты для новой функциональности Суматры, а также тестировать 
надежность и стабильность. Он знал, что этого человека будет трудно 


найти. 
№ этапа Этап Выполнено? 
А Получить разрешение на поиск кандидатов. М 


Для того чтобы провести анализ наличия умений и навыков группы 
тестирования на настоящий момент Джамал начал с создания ядра груп- 
пы тестирования проекта “Суматра”. В него вошли Эмма Мурхаус, уже ра- 
ботающий инженер по автоматизированному тестированию, и Лин Цу 


1 Дополнительные идеи по найму персонала я рекомендую поискать в учебнике Джоанны 
Ротман (Јоһаппа Кофтап) "Нігіп Тесіліса! Реоріє: А Сл4е го Ниш (ће Вірі Реоріє Юг 
те Їоб", который есть на ее сайте уу тотап.соп. Еще одна неплохая книга — “Тће 
Ассает Рғојесі Мапаре" Патрисии Энсворт (Раїгісіа ЕпзугогіН). 
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Ву, инженер по ручному тестированию. На основе проведенного анализа. 
все трое пришли к выводу, что должностные обязанности описаны в об- 
щем виде, но их суть отражена (см. рис. 8.1). Джамал отправил перечень 
должностных обязанностей для кандидатов на вакансии в различные 
группы новостей Интернета и в раздел вакансий рекламного отдела мест- 
ной газеты. 


№ этапа Этап Выполнено? 


1.В Определить параметры вакансии и подготовить рекламное М 
объявление. 


В ответ на рекламное объявление Джамал получил несколько резюме 
по электронной почте и факсу. Получая резюме, он сопоставлял навыки 
каждого из кандидатов с результатами анализа навыков группы тестиро- 
вания (см. рис. 8.2). В определенной степени это были гипотезы, и Джа- 
мал мог только предполагать на основе количества времени, проведенно- 
го в работе над проектами, требовавшими этих навыков, какой уровень 
знаний имеет или использовал каждый из кандидатов. Однако это помог- 
ло ему отсеять кандидатов, которые со всей очевидностью не соответст- 
вовали минимальным требованиям. 


Инженер автоматизированного тестирования 


Обязанности . 


Требуемая квалификация 


ш Участвовать в процессе выбора инструментов ав- 


томатизации тестирования. 


Разрабатывать и выполнять автоматизированные 
тесты, используя выбранный инструмент. 


Интегрировать комплекты тестов в систему управ- 
ления тестами и в заказные тестовые драйверы. 


Образование 


Бакалавр компьютерных наук, вычислительной 
техники или электротехники, либо наличие опыта 
работы не менее двух лет, либо сертификаты тес- 
тировщика. 


Опыт работы 


От пяти лет опыта работы по автоматизации тес- 
тирования. 


Требуется опыт тестирования УМХ-систем, осо- 
бым плюсом является опыт разработки заказных 
систем автоматизированного тестирования, 
включая знание языков разработки скриптов 
КеП, сѕћ и їСі. 


Желательно наличие опыта тестирования 
Интернет-приложений, включая разработку авто- 


ш Предпочтительно наличие подтвержденных карьер- 


ных устремлений, связанных с тестированием или 
контролем качества. Кандидат должен продемонст- 
рировать знакомство с теорией и практикой тести- 
рования и способность объяснить, как он применял 
эти знания на предыдущем месте работы. 


Прочее 
м Форма одежды деловая, свободная. Рабочий день 


ненормированный. Иногда нужно будет работать 
в выходные и в вечернее время. 


Рис. 8.1. Описание должностных обязанностей инженера 
по автоматизированному тестированию 
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Навыки н квалификация 


Общая квалификация 


‘Образование 


Степень бакалавра наук (85) (или выше) 


Обучение тестированию или наличие 
сертификата 


Прочее 


Опыт работы (лет) 

Должности, связанные с тестированием 
ИТ (не тестирование) 

Предметная область (не ИТ) 

Не предметная область (не ИТ) 
Итого/Все/Прочее 


Профессиональные качества 
Владение устной речью 
Навыки неформальной письменной речи 


Навыки подготовки формализованных 
документов 


Непрерывное обучение 


Участие в создании группы тестирова- 
ния/взаимное обучение 


Налаживание взаимоотношений с группами 


другой функциональной направленности 


Чтение (запоминание, способность 
к рассуждениям и анализу) 


Понимание тенденции развития отрасли 
и технологий (чтение профессиональных 
журналов) 


Навыки тестирования 


Общие навыки 
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Группа тестирования компании Ѕоћмаге Савета 
Таблица оценки умений и навыков 


0 = знания отсутствуют В = требуется 


З= керт 0 зжелатльно 


_ МТЕ = инженер по ручному | АТЕ = инженер по автомати- 
ТМ = тест-менеджор тестированию зированному тестированию 
з з 


> 
б 


1 = знания незначительны 


ТМ, 
Джамал 
Браун 


— 
2 
ы = 
Е = 
== 


Доктор фи- 
лософии 


(комоютер- | 85 (Бизнес) 


ные науки) 


Контроль ка- 
чества про- 


граммного 
обеспечения 
Дипломиро- 
ванный 
бухгалтер 


2 
о 
г 
г 


о < 
83 
АТЕ, 28 
минимум 5 5 
8 
МТЕ, 
минимум 


А РА 
за о 


Рис. 8.2. Анализ умений и навыков группы тестирования 
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Навыки и квалификация 


Стандарты тестирования 


Жизненные циклы разработки программ- 
ных продуктов 


Процессы тестирования/разработки 
и их зрелость 


Управление изменениями 


Связь тестирования и бизнеса/жизненные 
циклы разработки ПО 


Планирование 

Оценка затрат 
Подготовка документации 
Стоимость качества 


Риски качества/анализ видов ошибок 
и ИХ ВЛИЯНИЯ 


Анализ и управление рисками качества 


Проектирование и разработка тестов 


Поведенческое тестирование 
(черный ящик) 


Структурное тестирование (белый ящик) 


Статическое тестирование (требования, 
спецификации, документация} 


Тестирование надежности (статистика) 
Тестирование производительности 
Покрытие кода/лотоков данных 


Покрытие рисков хачества/требований 
(возможность отслеживания) 


Автоматизация (разработка) 


Выполнение тестов на готовых инструмен- 


тах (51К, Майдог и т.п.) 


Управление тестами с помощью готовых 
инструментов 


Разработка собственных инструментов 


Конфигурация 

Генераторы тестовых данных 
Версионный контроль 
Управление конфигурациями 


Компяексное тестирование 


Часть 11. Подготовка 


В = требуется 


0 = желательно 
АТЕ = инженер по автомати- 
зированному тестированию 


Е == 


Условные 


1 = знания ачительны 
обозначения з "ези 
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2 = хорошие знания 3 = эксперт 
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Рис. 8.2 (продолжение) 
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Навыки и квалификация 


Выполнение тестов: 

Ручное (скрипты) 

Ручное исследовательское 
Автоматизированное 

Локализация дефектов 

Подготовка отчетов о дефектах 
Подготовка отчетов о ходе тестирования 


Измерения тестирования 
{инструментальная панель) 


Навыки тестирования (в среднем) 


Знание предметной области 
Электронная обработка текстов: 
Приложения УМпдо\$ 
Приложения ИМХ 

Приложения Масіліоѕћ 
Графики и рисунки 

Таблицы 


Математические и инженерные формулы 


Управление документооборотом 
Приложения Міпӣомѕ 
Приложения ИМХ 

Приложения Масіпіоѕћ 

Прочее 


Управление иерархическими хранилищами 


Обмен документами 
Приложения Мілдомѕ 
Приложения ИМХ 


Приложения Масіпіоѕћ 


Печать, 
Цветная 
Лазерная 
Струйная 
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А = требуется 


0 = знания отсутствуют 1 = знания незначительны 


прете ари теа Ее 


д. МТЕ = инженер по ручному | АТЕ = инженер по автомати- 


в 


= 


о < 
8 5 
Е АТЕ, ЕЕ 
минимум 55 
Ж 
за 


А 


о 
м 


о 


2 
- 


РА 


> МТЕ, 
минимум 
ТМ, 
= м - Джамал 
Браун 


= 


- 


МТЕ, 
Лин Цу Ву 


рр АТЕ, 
ль носії | і а Эмма Мур. 
хаус 


> 
Я 


ші Минимум 
для групп! 
Е Б А: Среднев 
з |: о | за > ы В ы значение 
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Рис. 8.2 (продолжение) 
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Навыки и квалификация 


Печать/переплет 


Публикация в Ме 
НТМЬ 

ХМЕ 

Прочее 


Знание предметной области (в среднем) 


Технические знания 
Программирование 

САВ (360) 

ЈамаДС++) (Объектно-ориентированные) 
Скрипты ѕће!ї (ТсИКѕћ) 

Сложность и измерения кода 


Интернет-протоколы ТОРЛР, РЕР, ВСР 
Браузеры (№Меїѕсаре, ІЕ и т.п.) 


Архитектура сетевых приложений (ярусная) 


Аппаратное обеспечение сетей 


Системы и серверы 

Меб-серверь на зама 

Серверы баз данных 
Универсальные машины (таїпїгате) 


Технические знания (в среднем) 
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условные 
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Рис. 8.2 (продолжение) 
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№ этапа Этап Выполнено? 


1.С Найти и подвергнуть испытаниям кандидатов на основе резю- м 
ме, телефонных интервью; отсеять неквалифицированных и 
нежелательных кандидатов. 


С кандидатами, которые соответствуют требованиям, Джамал, Эмма и 
Лин Цу провели телефонные интервью, чтобы уточнить оценку навыков 
каждого из кандидатов. Джамал обратил особое внимание на вилку долж- 
ностного оклада, а также на путь развития карьеры, который может пред- 
ложить успешному кандидату компания 5оймаге Саїегегіа. 

Произошел дополнительный отсев, в результате которого в следую- 
щий раунд процесса найма вышли три кандидата. Джамал запланировал 
личное интервью с каждым из них. Обсудив планы с менеджером по рабо- 
те с персоналом, он решил, что кандидаты проведут половину рабочего 
дня, отведенного на интервью, следующим образом: 


1. Рассказ менеджера по работе с персоналом Боба Френкеля о компа- 
нии (0.5 часа), 


2. Интервью один на один с Джамалом (1 час). 


3. Групповое интервью за обедом сучастием Джамала, Эммы и Лин Цу 
(1 час). 


4. Выполнение контрольных заданий (1 час). 


5. Встреча с менеджером разработки Дженни Кауфман и менеджером 
проекта Кейт Эрнандес (0.5 часа). 


6. Краткое подведение итогов с Бобом Френкелем. 


Боб Френкель позвонил каждому из кандидатов и определил дату 
и время встреч. 

Два интервью прошли самым обычным образом. Кандидаты казались 
достаточно компетентными, но одного из них в ходе интервью постоянно 
отвлекали звонящий сотовый телефон и какие-то личные дела, связанные 
со списком покупок в продуктовом магазине. Его вопросы в основном были 
связаны с тем, чтобы от него не требовалось работать более 45 часов в не- 
делю. Постоянно возникали замечания о “необходимости иметь возмож- 
ность получать удовольствие от жизни, а не только работать”. Джамал по- 
нимал, что эти соображения справедливы, особенно в мире высоких 
технологий и запуска новых продуктов, но даже после того как он сообщил 
о своей приверженности к ограничению переработок, кандидат продол- 
жал намекать, что данная вакансия может потребовать большой загрузки и 
работы в выходные. Другая кандидатка, хотя и более деликатная, дважды 
упомянула, что она не в восторге от предложенной зарплаты, и спросила, 
есть ли какая-либо “возможность для переговоров” по этой цифре. 
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Часть И. Подготовка 


Однако третье интервью с кандидатом, резюме которого показано на 
рис. 8.3, прошло очень хорошо. Динеш, очевидно, обладал необходимы- 
ми навыками, а также продемонстрировал положительное отношение к 
вакансии. Динеш сказал Джамалу и Эмме, что с ростом его семьи ему пора 
заканчивать работать по контрактам, с короткими проектами, неопреде- 
ленностью будущего и ненадежной медицинской страховкой. Он выра- 
зил желание устроиться на долгосрочную работу в стабильной компании, 
что смягчило беспокойство Джамала по поводу того, что Динеш часто ме- 
нял работу, будучи контрактником. 

В качестве контрольного задания Джамал и Эмма попросили Динеша 
выполнить один изавтоматизированных тестов. Он с этим успешно спра- 
вился, заметив не только ошибку в продукте, но и подозрительное поведе- 
ние самих автоматизированных скриптов. Лин Цу проверила отчет об 
ошибке, написанный Динешем, и сочла его проникающим в суть, лако- 
ничным И полным. 


№ этапа Этап Выполнено? 


1.р Провести личные интервью с квалифицированными и жела- м 
тельными кандидатами. 


Поскольку обсуждение, которое провел Джамал с Эммой, Лин Цуи Бо- 
бом Френкелем по результатам интервью, было весьма позитивным, Джа- 
мал решил принять Динеша на работу. На основе перечня должностных 
обязанностей и результатов оценки навыков Боб и Джамал написали пись- 
мо с предложением о занятии вакансии. Для дополнительного введения 
Динеша в курс дел Джамал запланировал для Эммы один час в день на кура- 
торство Динеша, начиная с момента его выхода на работу, а также попро- 
сил Боба подготовить для Динеша самую свежую копию справочника со- 
трудника. Он также приступил к планированию однодневного обучения 
для Динеша и новых младших тестировщиков в течение следующих трех- 
четырех недель. 


№ этапа Этап Выполнено? 


Е Если есть подходящие кандидаты, сделать предложение наи- М 
более успешному из них, как правило, направив ему соответст- 
вующее письмо. 


1.Е Если наиболее успешный кандидат принимает предложение, 
принять нового сотрудника на работу. Если нет, повторить 
этапы 1.Е и 1.Е для каждого следующего по успешности кан- 
дидата, пока успешный кандидат не примет предложение, 
или, если ни один из желательных кандидатов не принял 
предложение, начать процесс заново с этапа 1.А. Уведомить 
отвергнутых кандидатов, что они должны выбирать другие 
варианты. 


Я Крис Денардис (Сһгіѕ ОеМагаіѕ) в статье “Регѕресііуеѕ Егот а Тез Мапарег” в журнале 


"За/тшате Теѕітр апа Оиаїйу Епріпеегіпр", Моїште 2, Іѕѕие 5 (ер / Осі 2000), доступной в настоя- 
щее время на ммуг.5іскутіпадз.сот, рекомендует проводить обучение самому программному 
продукту, а также выпускать руководство тестировщика для всех вновь принятых на работу 
тестировщиков. 
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Динеш Кумар 


Профессиональный 
опыт 


2000 — наст. время Оепіа!180 Буффало, штат Нью-Йорк 
Старший инженер-тестировщик, консультант 


• Разрабатьвал средства тестирования для набора инструментальных 
средств (8ОК) компании. Разрабатывал систему тестов для динами- 
чески генерируемых тестовых сценариев для мер-приложения. Раз- 
рабатывал инструмент автоматизированного тестирования для гра- 
фического интерфейса, управляемый данными, с использованием 
Зедие $1кТеѕї. Проводил настройку исходных нагрузочных тестов с 
помощью Ѕедие 5іїкРегіогтег. 


1999 — 2000 ОеѓипсіВапк Провиденс, штат Род-Айленд 
Старший инженер-тестировщик, консультант 
• Оценивал и разрабатывал инструменты тестирования, а именно 
средства автоматизации тестирования, отслеживания проблем и 
$СМ. Разрабатывал функциональные, нагрузочные тесты и тесты 
для проверки производительности для меб-приложения финансово- 
го назначения с помощью Мегсигу Іпіегасіїме Гоа9Виппег. 


1999 Визфиске{ Моюг Сгедії Детройт, штат Мичиган 
Старший инженер-тестировщик, консультант 


• Разрабатывал процессы тестирования и контроля качества для сре- 
ды разработки клиент-серверных приложений. Оценивал инструмен- 
ты автоматизации тестирования, давал рекомендации по приобрете- 
нию и готовил определение инфраструктуры автоматизированного 
тестирования. 


1998 — 1999 Зіагб9 Калгари, провинция Альберта 
Старший инженер-тестировщик, консультант 


• Разрабатывал планы тестирования и процедуры автоматизирован- 
ного и ручного тестирования для клиент-серверного приложения на 
основе телефонной системы частного пользования. Тестовая сре- 
да — ОА Райпег на МТ 4.0. 


1998 — 1999 ВЕЗР боймаге Уимбердудл, штат Пенсильвания 
Инженер по контролю качества 


® Разрабатывал планы тестирования и процедуры для автоматизиро- 
ванного и ручного тестирования миграции баз данных, утилит обнов- 
ления и конверсии. Тестовая среда — ОА Райпег на МТ 4.0 и клиенты 
Міпаом5 98. 


1996 — 1998 Оеїепсебіапі Сизтл, штат Вашингтон 
Инженер по контролю качества 


• Разрабатывал планы тестирования и процедуры для автоматизиро- 
ванного и ручного тестирования систем регистрации и вспомогатель- 
ных утилит военного назначения. Оценивал системы управления де- 
фектами для принятия решения о выборе. Тестовая среда — 
Міпаомѕ МТ 4.0/3.51 и клиенты Міпаомѕ 9х с серверами НРИХ Огасіе, 
использующими ОА Раппег. 


Рис. 8.3. Резюме успешного кандидата Динеша Кумара (Оіпе5п Китаг) 
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Профессиональный 
опыт 


Часть И. Подготовка 


1994 — 1996 ВідТеѕіСотрапу Орландо, штат Флорида 
Инженер по контролю качества 

• Разрабатывал планы тестирования и процедуры для автоматизиро- 

ванного и ручного тестирования для различных продуктов іпіегѕоім 


РУС, включая Мегѕіоп Мападег и Тгаскег. Тестовая среда — ОА 
Рапйпег на Міпаомѕ МТ 4.0 и 3.51 и Мпаомѕ 95 и 3.1. 


1989 — 1994 ОепѕеВуїе . Альбукерк, штат Нью-Мексико 
Инженер по контролю качества 
• Разрабатывал, сопровождал и выполнял тестовые процедуры для 
Оепѕіу, системы восстановления баз данных и генерации отчетов. 
Тестовая среда — АшоТезег, скрипты ОМІХ эне!, УМЗ ОСЕ и С на 
УМХ, УМ$, 90$ и Міпомѕ. 


1988 — 1989 ВепзеВуе Альбукерк, штат Нью-Мексико 
Программист-аналитик 
• Разрабатывал программные продукты, используя утилиты распозна- 
вания образов, созданные в компании. Приложения включали в себя 
систему исследования баз данных. Вся разработка велась на персо- 
нальных компьютерах с использованием языка Си. 


1988 — 1988 Верепа$ Альбукерк, штат Нью-Мексико 
Программист-аналитик 
• Разрабатывал дополнения и участвовал в системной поддержке при- 
ложения для демонстрации преимуществ страхования жизни для 
персональных компьютеров. Приложение было конвертировано 
с языка Фортран на С. 


1986 — 1988 Від Маѕѕіме Ойну Альбукерк, штат Нью-Мексико 
Программист-аналитик 
• Разрабатывал программы управления межпроцессорным обменом 
на Фортране для УАХ./Л/М$ для системы учета расхода газа и элек- 
троэнергии ЗСАПА. Приложения обмена включали в себя графиче- 
ское представление, модуль удаленной передачи данных и поддерж- 
ку пользовательского приложения для системных сервисов. 


1986 — 1986 Зсогрюп Тесп Альбукерк, штат Нью-Мексико 
Программист-аналитик 


• Участвовал в разработке фрагмента торговой системы под управле- 
нием процессора на базе ЗМУТРС 68010. 


1985 — 1986 Цабігіпі, пс. Альбукерк, штат Нью-Мексико 
Программист-аналитик 


• Оказывал помощь в проектировании и разработке языка четвертого 
поколения и системы разработки приложений для персональных 
компьютеров. Разрабатывал пользовательскую документацию. 


1984 — 1985 ТеіСотбмуісп Альбукерк, штат Нью-Мексико 
Программист-аналитик я 


• Разрабатывал и сопровождал программу пользовательского интер- 
фейса для главного компьютера телекоммуникационной системы. 
Проектировал и разрабатывал программы для поддержки распреде- 
ленной архитектуры АСО86 1.3. Координировал работу с технически- 
ми писателями для обеспечения полноты и точности пользователь- 
ской документации. 


Рис. 8.3 (продолжение) 
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Профессиональный 
опыт 


Статьи 


Образование 


1981 — 1984 Раїит$рћеге Альбукерк, штат Нью-Мексико 
Специалист по сертификации программных продуктов 
• Сертифицировал программы для телекоммуникационных 
систем, устанавливал требования и определял процедуры 
для тестирования на основе анализа спецификаций архитек- 
туры и функциональности; проектировал и кодировал систе- 
мы тестов. 


1979 — 1981 Сһаоѕ Сотрийпд Финикс, штат Аризона 
Программист-аналитик 
• Разрабатывал и сопровождал программы для интерактивных 
графических геосистем. Проектировал и разрабатывал про- 
граммы для доступа к графическим и неграфическим базам 
данных и переформатирования информации для выдачи от- 
четов. 


1979 — 1979 Рогко Альбукерк, штат Нью-Мексико 
Программист-аналитик 
• Разрабатьвал и сопровождал программы для университе- 
тов, главным образом интерактивные программы для науч- 
ных и деловых приложений. Консультировал преподавателей 
и студентов. 


1978 — 1979 Вгаіпіак Цпім. Уимбердудл, штат Пенсильвания 
Программист-аналитик 
• Разрабатывал программу для сбора данных в реальном вре- 
мени для исследований сердечной деятельности. Разрабаты- 
вал программы для анализа данных, поддерживающие про- 
грамму сбора данных. 


Ноябрь, 1996 ЕџгоСопѓегепсе Париж, Франция 
» Чтедгаед Теѕї Аціотаїоп" в соавторстве с Бобом Джоунзом 
(Воб Јопеѕ), Дженной Брюкером (Чеппа Вгискег) и Эмамали- 
ни Чоудри (Нетатаїпі Сһомагу). 
1975 — 1977 Вгапіас Упм. Уимбердудл, штат Пенсильвания 


Рис. 8.3 (продолжение) 
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Выявление ключевых навыков тестировщика 
и управление ими 


Одним из важнейших инструментов, только что представленных в главном 
примере книги, является подготовленная Джамалом таблица ключевых уме- 
ний и навыков группы тестирования. Он использовал этот документ для 
подготовки первоначального рекламного объявления о вакансии, для отсеи- 
вания резюме и для подготовки описания должностных обязанностей. Как 
бы вы подготовили такую же таблицу для ваших групп тестирования? 

Первым делом нужно определить, какие умения и навыки являются 
критическими для группы тестирования. Мне нравится применять для 
этого нисходящий подход. Если внимательно посмотреть на рис. 8.2, 
можно заметить, что я выделил четыре основные категории навыков: об- 
щая квалификация, навыки тестирования, знание предметной области и 
технические знания. 

Первая категория, общая квалификация, обычна для большинства ком- 
паний. Здесь описывается некоторый базовый уровень навыков и образо- 
вания, необходимый для занятия должности. Для специалистов-тестиров- 
щиков, т.е. для поставщиков информационных продуктов и услуг, помимо 
прочего, имеет большое значение умение доносить свои мысли в письмен- 
ной и устной форме как формально, так и в неформализованной среде. 
Также для статического тестирования в форме рецензирования, инспек- 
ций и просмотров необходимо умение тщательно читать документы с боль- 
шим вниманием к деталям. 

Однако больший интерес представляют области навыков тестирова- 
ния, знания предметной области и технические знания. Считаю полез- 
ным изобразить навыки в трехмерном пространстве, как показано на 
рис. 8.4. Мы можем разместить различных сотрудников группы тестиро- 
вания в этом пространстве на основе их специфических навыков, а также 
сделать обобщения по поводу того, как различные должности отобража- 
ются в этом пространстве. 

Различные проекты и группы предъявляют различные требования 
к каждой из этих трех областей. В группе тестирования проекта “Сумат- 
ра” знание предметной области является низшим уровнем компетентно- 
сти группы тестирования. Это правильно? Ответ зависит от продукта. 
Текстовый процессор — это простое приложение, знакомое большинству 
пользователей компьютера. Хотя текстовые процессоры сейчас содер- 
жат массу модных “примочек”, большинство пользователей текстовых 
процессоров применяют весьма узкое подмножество свойств. Даже если 
принять во внимание огромное число планов тестирования, статей 


Этот инструмент я придумал сам много лет назад. Другие тестировщики разработали по- 
хожие инструменты. Таблица ключевых навыков, представленная в этой главе, содержит 
многие идеи, которые используются в таблице оценки навыков, разработанной Енг Нгуе- 
ном (Нипр Момеп). Я благодарю Енга и компанию ЇоріСєаг Согрогайоп (угмумг.1.0р1- 
Сеаг.сот) за предоставленную версию. Джеймс Бах (Јатеѕ Васі), Берни Бергер (Вегпіе 
Вегрег) и Элизабет Хендриксон (ЕНзабеїБ. Непагіскѕоп) также предоставляют несколько 
идей, касающихся ключевых навыков, необходимых тестировщикам. 


Глава 8. Поиск искусных тестировщиков 235 


Знание предметной области 


Бизнес- 
аналитики 


Инженеры 
по ручному 
тестированию 


Младшие 
тестировщики 
Навыки 

тестирования 


Администраторы | Разработчики Инженеры 
систем инструментов по автоматизи- 
тестов тестирования рованному 

тестированию 


Технические знання 


Рис. 8.4. Пространство навыков и должности тестировщиков 


Умения и навыки г тестирования (Тезнав кіз). 


Б Квалификационные способності и ‘относящиеся к ‘выполнению задач те У 
‘тирования, например к разработке качественных тестовых е ариев и 


Навыки в предметной области приложения, ‚экспертиза в! предметной 
‘области (Аррісагіоп Рошаїп $1115, Ѕирјесе Мацег Ехрегії 


(Навики или знания, относящиеся к какой-либо области или к. решае | 
задачам в программном или аппаратном обеспечении; другими словами, 
понимание того, как заказчики и пользователи моли применять А 


траммирования или серверную 1 и рани архитектуру. 


и книг, написанных мной, подозреваю, что я использую примерно 20% 
возможностей моего текстового процессора. 

Рассмотрим в качестве противоположного примера компанию одного 
из моих клиентов. Они пишут геологическое программное обеспечения 
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для поиска нефти. Это настолько сложное приложение, что даже их соб- 
ственная группа тестирования, составленная полностью из геологов, гео- 
физиков и других подобных специалистов, не может целиком понять и 
протестировать все типичные сценарии использования системы. В ре- 
зультате эта группа тестирования вынуждена приглашать на фазу систем- 
ного тестирования некоторых наиболее активных пользователей из чис- 
ла своих заказчиков в качестве гостевых тестировщиков. 

Процесс найма персонала оказывает влияние на совокупность навы- 
ков группы тестирования и находится под влиянием этой совокупности. 
Группа тестирования Суматры начала работу, имея совокупность навы- 
ков, представленную на рис. 8.2. Предположим, что мы обобщили эту 
информацию для различных категорий навыков. Тогда совокупность на- 
выков группы тестирования на верхнем уровне детализации будет выгля- 
деть, как показано на рис. 8.5. 

В небольших группах тестирования, как эта, важно иметь всесторонне 
подготовленную группу специалистов. Таким образом, частью процесса 
найма Динеша был учет того, как он заполняет пробелы в квалификации 
и увеличивает совокупные возможности группы тестирования. После 
того как Динеш приступил к работе, совокупные навыки группы тестиро- 
вания изменились, как показано на рис. 8.6. Динеш, очевидно, — самый 


Моогћоизе 
Теага 
Мапігпигао 


е 
Е 
8 

[52] 
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Рис. 8.6. Краткая сводка совокупных навыков группы тестирования после 
принятия на работу Динеша Кумара 
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сильный сотрудник группы (исключая навыки управления) и поднимает 
группу в среднем по техническим знаниям и навыкам тестирования. Ис: 
пользование взаимного обучения даст возможность Динешу поделиться 
своими умениями с остальной частью группы, поднимая средние значе- 
ния еще выше. К этой теме я вернусь в следующей главе. 


0 младших тестировщиках 


Джамал планировал взять на работу не только Динеша, ему еще нужно на- 
нять четырех младших тестировщиков по контракту. Должность младшего 
тестировщика, вероятно, не знакома читателю, поэтому позвольте мне 
объяснить, что я имею в виду. Я ищу и нанимаю младших тестировщиков — 
наименее оплачиваемых и наименее квалифицированных сотрудников 
группы тестирования — для выполнения ручных и автоматизированных 
тестовых сценариев, подготовки отчетов о результатах тестирования и де- 
фектах и прочих работ, поручаемых им инженерами-тестировщиками. Ко- 
гда я разговариваю с людьми о младших тестировщиках, у них часто возни- 
кают вопросы и различные идеи. Что такое младший тестировщик и где 
его найти? Как заставить работать эти взаимоотношения и на работодате- 
ля, и на сотрудника? Не противоречит ли использование младших тести- 
ровщиков тому, что тестировщикам требуются навыки в технологиях 
и тестировании и знания предметной области? 

Что касается навыков, необходимых для выполнения работы, опреде- 
ленно существует много задач тестирования, требующих навыков или 
знаний в используемой технологии разработки, предметной или про- 
блемной области системы и, не в последнюю очередь, в тестировании. 
(Под навыками тестирования я понимаю все навыки, необходимые для 
ключевых процессов тестирования, обсуждаемых в этой книге, а также 
другие навыки тестирования, в том числе проектирование, документиро- 
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вание тестов и знание теории автоматизированного и ручного тестирова- 
ния, а не только выполнение тестов.) Для выполнения этих задач нужны 
инженерьгтестировщики, люди, обладающие навыками, опытом и зна- 
ниями инженера-программиста, но в своей работе ориентированными на 
тестирование. 

Однако также верно, что многие задачи тестирования, особенно 
ручное регрессионное тестирование с помощью скриптов, установка 
программ для тестирования и конфигурирование систем тестов, могут 
быть механически повторяющимися действиями. В некоторых случаях 
автоматизация не является практичным решением. Например, если 
группа тестирования выполняет регрессионное тестирование систе- 
мы с нестандартным интерфейсом, инструменты автоматизации тес- 
тирования могут не поддерживать такой интерфейс, и нет времени на 
разработку средства автоматизированного тестирования внутри ком- 
пании. Вместо использования дорогих, высококвалифицированных 
инженеров-тестировщиков я предпочитаю нанимать младших тести- 
ровщиков для выполнения обязанностей, связанных с тестированием 
вручную. 

Признание, что некоторые задачи тестирования являются механиче- 
скими и повторяющимися и находятся в рамках возможностей менее 
квалифицированных сотрудников, не противоречит тому, что тестиро- 
вание само по себе предполагает уникальную квалификацию. Наличие 
младших тестировщиков в группе тестирования не должно нарушать их 
прав и лишать их уважения со стороны других сотрудников компании. 
Кроме того, тест-менеджер может назначать ответственными за выпол- 
нение определенных задач как инженеров-тестировщиков, так и млад- 
ших тестировщиков на основе их навыков. Наличие младших тестиров- 
щиков должно способствовать укреплению духа коллектива, а не 
наносить ему ущерб. 

Вряд ли кто-то представит, что шеф ресторана менее квалифициро- 
ван, раз он нанимает людей мыть посуду; или поскольку в Белом доме есть 
стажеры, быть президентом -- это работа низкой квалификации. Мы сами 
пользуемся преимуществами, предоставляемыми различиями в умениях 
и навыках в повседневной жизни и бизнесе. На самом деле, я бы мог дока- 
зать, что невозможность задействовать младших тестировщиков и прину- 
ждение инженеров-тестировщиков выполнять работу, не требующую их 
уровня квалификации и опыта, действительно наносит ущерб имиджу 
тестирования как профессии, а также приводит к бессмьтсленному расхо- 
дованию денег. 

Младшие тестировщики приходят из разных мест и имеют за плечами 
разный опыт. Рекламное объявление, размещенное в местной газете и в 
Интернете, обычно приводит к обращениям большого количества квали- 
фицированных кандидатов во многих регионах США. Я пониманию, что 
в некоторых местах США, а также в большей части Европы и Азии тест- 
менеджеры испытывают трудности в поисках квалифицированных млад- 
ших тестировщиков и в их продуктивной загрузке после приема на работу 
из-за различий в рынках труда, профессиональных ожиданий, несоответ- 
ствия доходов и т.п. Тем не менее, попробовав использовать младших тес- 
тировщиков, многие поражаются, как просто создать рабочее место для 
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таких людей в группе тестирования, насколько они производительны, 
и как каналы, с помощью которых никогда не найти инженеров-тестиров- 
щиков, оказываются полезными для поиска и найма младших тестиров- 
щиков. 

Как показывает опыт проектов, в которых я участвовал, лучшие млад- 
шие тестировщики делятся на следующие три категории: 


и Студенты или недавние выпускники, особенно технических вузов 
или программ сертификации. 


= Специалисты, выбравшие новый, второй путь продолжения карье- 
ры, особенно уволенные в запас военные, которые хотят найти 
себя в компьютерном бизнесе. 


и Бывшие специалисты по технической поддержке, сетевых систем 
поддержки, а также персонал центров обработки вызовов, особен- 
но имеющие опыт работы с применяемой технологией или пред- 
метной областью. 


Однако нужно забрасывать сети достаточно широко. Можно позво- 
лить себе установить планку для младших тестировщиков довольно низ- 
ко, поскольку мы собираемся их обучать тому, что они должны знать. Что 
действительно важно для младших тестировщиков, так это желание 
учиться, самостоятельность, способность к напряженной работе и пра- 
вильное отношение к ней. 

Нужно обязательно планировать обучение младших тестировщиков. 
Для младших тестировщиков, работающих по контракту, я использую на- 
значение кураторов из числа инженеров-тестировщиков и однодневное 
обучение. Для постоянных сотрудников, выбравших карьеру в вашей ком- 
пании, или в случае сложных приложений может потребоваться более 
серьезное обучение и наставничество. Начинающие младшие тестиров- 
щики нуждаются в обучении основам тестирования: управлению рисками 
качества с помощью тестирования; концепциям структурного и поведен- 
ческого тестирования, ручного и автоматизированного тестирования; 
выполнению скриптов для ручного тестирования; написанию хороших 
отчетов о дефектах. Им необходимо рассказать о других документах, с ко- 
торыми они могут встретиться (например, о плане тестирования), о том, 
как тестирование встраивается в жизненный цикл разработки, об эконо- 
мике производства программных продуктов и о проблемах, возникаю- 
щих в ходе выполнения тестов. 

Также необходимо организовать дополнительное наставничество 
и руководство младшими тестировщиками, особенно не имеющими серь- 
езного опыта работы. Действительно, есть большая разница в подходе 
к младшему персоналу и опытным специалистам. У меня работали два 
младших тестировщика, которые быстро справились с серьезными тех- 
ническими трудностями и пришли за новыми заданиями раньше, чем 
я ожидал. У меня также работал младший тестировщик, который часами 
просиживал без дела в тестовой лаборатории, ожидая появления новой 
версии, не заботясь о том, чтобы позвонить или эскалировать возникшую 
проблему. (Все три младших тестировщика были недавними выпускника- 
ми компьютерных факультетов ведущих университетов.) Трудно заранее 
точно оценить, как человек будет работать в качестве младшего тестиров- 
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щика, позтому нужно внимательно наблюдать и при необходимости вно- 
сить коррективы в его работу. 

Это может показаться довольно хлопотливым делом, но оно того 
стоит. Во-первых, вам удастся избежать недовольства опытных тести- 
ровщиков по поводу работы, которую они считают глупой, и тем самым 
повысить моральное состояние группы. Во-вторых, при разумном ис- 
пользовании младших тестировщиков компания может сэкономить 
большую сумму денег, что может сделать предусмотрительного тест- 
менеджера, нанимающего младших тестировщиков, героем, а также 
предоставит ему возможность работать с более внушительной по раз- 
меругруппой и выполнять больший объем тестирования, чем это было 
бы в противном случае. 

В-гретьих, но не в последнюю очередь, тест-менеджера, получающего 
шанс-другой поработать с младшими тестировщиками, которые кажутся 
недостаточно квалифицированными, может ожидать приятный сюр- 
приз. Были такие младшие тестировщики, которые меня разочаровали. 
Но болынинство оправдали мои ожидания относительно того, что они 
должны делать. По крайней мере, могу вспомнить троих, которые, по мо- 
ему мнению, были одними из лучших сотрудников. У вас всегда есть воз- 
можность дать человеку отдохнуть, перевести его на другую должность, 
на другую работу, позволить ему сменить направление развития карьеры. 
Я бы рекомендовал не зацикливаться на незначительных и абсолютно не- 
существенных отличиях в одном или двух годах опыта работы, степени 
бакалавра или незаконченного образования бакалавра, а создать ниж- 
нюю ступеньку в вашей компании, чтобы принимать людей, которые смо- 
гут стать вашими лучшими сотрудниками. 


Варианты состава группы тестирования: 
временное назначение, ротация, 
команда-питомник и тихая заводь 


До настоящего времени мы рассматривали найм новых сотрудников 
и развитие карьеры с неявным предположением, что люди присоединя- 
ются к группе тестирования, работают в ней на протяжении некоторого 
периода своей карьеры, а затем занимают более высокие технические 
или руководящие должности в компании. Это, конечно, один путь разви- 
тия карьеры, причем вполне обычный, но едва ли единственный. Мне из- 
вестны несколько распространенных альтернатив, которые заслуживают 
упоминания. 

Первый вариант — это временное назначение сотрудников, работаю- 
щих где бы то ни было в компании, в группу тестирования. Эти люди 
могут усиливать группу тестирования в период выполнения тестов или 
работать в ней в течение всего проекта. Эту роль нередко играют пользо- 
ватели и сотрудники группы технической поддержки разрабатываемой 
системы. Они вносят значительный вклад в знание предметной области 
в ходе тестирования. Если этих сотрудников можно включить в группу 
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тестирования на этапах планирования и подготовки, которые рассматри- 
ваются в первых двух частях книги, они также помогут убедиться, что тес- 
тирование отражает реальные потребности пользователей. 

Такой подход бывает эффективным, особенно когда сотрудники по- 
полняют существующую группу инженеров-тестировщиков. В этих слу- 
чаях приток знаний предметной области часто заполняет вакуум в со- 
вокупности навыков группы тестирования, что в противном случае 
привело бы к серьезным упущениям. В качестве примера напомню ра- 
нее упомянутых разработчиков программ для поиска нефти. Тестиров- 
щики, приглашенные из крупнейших компаний-заказчиков, участвова- 
ли в системном тестировании. Они принесли свои наборы данных. 
И им предоставили возможность тестировать систему так, как они ее 
используют. Это позволило проверить основные сценарии использо- 
вания системы и данных, которые в противном случае оказались бы не- 
исследованными. 

Тем не менее могут возникнуть проблемы, если группа тестирования 
состоит только из временных сотрудников. Такие группы независимо от 
того, кто включен в них — эксперты в проблемной области или техниче- 
ские специалисты, — обычно испытывают недостаток навыков тестиро- 
вания. Однажды я наблюдал за проектом продолжительностью в несколь- 
ко лет и с многомиллионным бюджетом, который частично провалился, 
поскольку сотрудникам, не умеющим тестировать, были поручены все 
ключевые работы по тестированию одной из подсистем. 

Другой альтернативой является ротация, подход, который, по всей ве- 
роятности, не является столь традиционным, как он того заслуживает. 
Например, сотрудники могут переводиться из группы разработки в груп- 
пу тестирования, из группы тестирования в группу технической поддерж: 
ки, из группы технической поддержки в группу программистов и т.д. Дру- 
гими словами, эти три группы можно рассматривать как техническую 
команду системы и изменять обязанности ее членов каждые несколько 
месяцев. В ходе ротации при помощи менеджеров, которые отслеживают 
состояние умений и навыков каждого сотрудника и всей руководимой 
ими группы, люди получают всестороннее развитие навыков. Специали- 
сть, которые рассказывали мне о таком подходе к робо, единогласно 
выражали удовлетворение его результатами. 

Использование ротации приводит к тому, что все менеджеры, через 
чьи группы проходят люди, соглашаются с таким подходом. Отдел управ- 
ления персоналом, если он есть, также нуждается в поддержке таких воз- 
можностей для сотрудников. Менеджеры должны убедиться, что сотруд- 
ники, которых планируется перемещать на другие позиции, понимают 
цели и согласны с назначениями. Для того чтобы контролировать, что 
люди, перемещенные на новые должности, получили назначения, соот- 
ветствующие их набору навыков (в противном случае ротация может от- 
рицательно сказаться на производительности и эффективности работы 
одной или всех групп), необходимо тщательное управление структурой 
и навыками группы. Поскольку перемещение в группы тестирования и 
технической поддержки обычно рассматривается программистами как 
нежелательное, для реализации такого плана необходимо наличие опре- 
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деленных навыков управления. Новые сотрудники также должны заранее 
знать о планах ротации. 

Я также слышал о пользе ротации от тест-менеджеров, работающих 
в компаниях, в которых группа тестирования является местом, где новые 
сотрудники, в частности, имеющие намерения заниматься программиро- 
ванием, проводят некоторый период времени, изучая продукт. Тест- 
менеджеры, руководящие такими группами, говорят, что этот подход по- 
лезен для компании в целом. Однако у меня есть три замечания. 

Во-первых, подход способствует увеличению знания предметной об- 
ласти и технической экспертизы, что является ключевым фактором эф- 
фективного тестирования, но сводит к минимуму навыки, относящиеся 
именно к тестированию. Кроме того, как отмечалось в главе 1, довольно 
сложно убедить тестировщика в этой роли повышать навыки тестирова- 
ния, поскольку рост этих навыков не соответствует его карьерным уст- 
ремлениям. Во-вторых, непрерывная текучка в группе тестирования до- 
бавляет новые проблемы тест-менеджеру, который и без того достаточно 
занят. Мне кажется, что для того чтобы заставить этот подход работать, 
тест-менеджер и, естественно, вся компания должны совместно работать 
в поисках решения этих проблем. 

Третья проблема, касающаяся использования группы тестирования 
в качестве тренировочного полигона возникает в том случае, когда вы 
понимаете, что не можете выдвигать на другие роли одного или несколь- 
ких сотрудников. Некоторые люди могут по каким-то причинам не под- 
ходить для перемещения в другие группы, и менеджеры этих групп отка- 
жутся принять их. Проблема не является спецификой именно этого 
подхода, но возникает всегда, когда группа тестирования становится ти- 
хой заводью или болотом для сотрудников, отвергнутых другими под- 
разделениями компании. Это, естественно, наиболее проблемная ситуа- 
ция для ведущего тестировщика или тест-менеджера при построении 
группы тестирования. Когда я сталкивался с ней, для меня неявным по- 
сылом был следующий: “Здесь можно работать с людьми, которые счита- 
ются нежелательными по разным причинам; нужно идти и проводить 
тестирование в существующих условиях”. Некоторые из этих людей пре- 
вратились в первоклассных тестировщиков, в то время как другие оказа- 
лись для меня неисчерпаемыми источниками проблем. 


Роберт Сабурин (Кобегт Забоигілп), главный консультант компании АпиБир и один из ре- 
цензентов этой книги, также сообщил об огромном успехе хорошо подготовленной про- 
граммы ротации. Он писалмне: “Я использовал много вариантов ротации. Одним излучших 
себя зарекомендовал следующий. Сотрудники групи обучения пользователей, технической 
поддержки, инсталляции и даже разработки назначаются на один день каждый месяц все 
без исключения, даже менеджеры, в группу тестирования. В течение этого дня они работа- 
ют над выполнением, проверкой и даже проектированием пользовательских сценариев 
и соответствующих тестовых процедур. Мы превратили это занятие в развлечение, которое 
приносит большую помощь тестированию, обогащает новыми знаниями все группы и повы- 
шаетуважение к работе, выполняемой группой тестирования. Преподаватели, технические 
писатели, сотрудники поддержки получают возможность заранее “поиграть” с новыми про- 
дуктами и получают представление о том, что появится в конце разработки. Кроме того, все 
привлекаемые программисты повышают свои навыки в модульном тестировании и более 
напряженно работают над тестами, предназначенными для проверки состояния системы 
внутри группы программистов, и тестами для приемочного тестирования версий перед пе- 
редачей сборок группе тестирования!” 
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Вы могли подумать, что включение сотрудников в свою группу будет 
оценено как средство добиться расположения других менеджеров, одна- 
ко мой опыт показывает, что это не так. Однажды я работал с менедже- 
ром по маркетингу, который решил, что один из программистов испор- 
тил его любимое свойство системы. На самом деле из-за неспособности 
определить требования кэтому свойству системы менеджер по маркетин- 
гу решил возложить вину за результат на программиста. 

Программист был переведен в качестве наказания в группу тестирова- 
ния, но всякий раз, когда приходило время важных проектов тестирова- 
ния, этот маркетолог хотел немного поуправлять тестированием, настаи- 
вая на том, чтобы упомянутому экс-программисту не доверяли “работать 
ни с чем важным”. Молчаливое согласие с этим назначением с надеждой 
избежать политических волнений позволило мне только сузить про- 
странство для собственного маневра. Мои возможности стали ограничен- 
ными, и на все, что я поручал несчастному экс-программисту, накладыва- 
ли отпечаток его предыдущие неудачи. Я рекомендую избегать таких 
ролей на задворках. Определение перечня умений, навыков, уровня обра- 
зования и опыта, необходимых для инженера-тестировщика или младше- 
го тестировщика в группе тестирования, выступает в качестве одного из 
элементов установления входного барьера на достаточной высоте, чтобы 
не допустить подобных неприятностей. 

После создания группы тестирования, если это не временный коллек- 
тив сотрудников, созданный на один раз для тестирования продукта и не 
требующий непрерывной поддержки, необходимо строить команду во- 
круг этих людей. Группа должна обладать соответствующими навыками, 
опытом и знаниями для успешного проведения тестирования. Тестиров- 
щики должны иметь правильное отношение к работе, чтобы четко. вы- 
полнять свои обязанности и без проблем взаимодействовать с остальной 
частью группы проекта. А для поддержания мотивации работа, которую 
выполняет каждый тестировщик, должна соответствовать его карьерным 
устремлениям. 


Образование, дополнительное обучение, 
сертификация и превращение тестирования 
в профессию 


Надлежащее образование тестировщики могут получить в разных мес- 
тах. Во-первых, есть колледжи. В примере на рис. 8.1 степень бакалавра 
является одним из требований для инженеров-тестировщиков. Я также 
отмечал в качестве требования непрерывное обучение. Некоторые ком- 
пании предоставляют помощь сотрудникам в получении степени маги- 
стра и даже доктора. 

Но нужно ли тестировщикам формальное образование? Обычно я от- 
даю предпочтение инженерам-тестировщикам, окончившим колледж. 
Любые обобщения опасны, но, по моему мнению, четырехлетнее обуче- 
ние или более высокая степень образования означает некоторое упорст- 
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во вкомбинации со способностью осваивать сложный материал, и это по- 
зволяет людям быть полезными. 

Некоторые говорили мне, что считают необходимым, чтобы все 
тестировщики окончили колледж, если это требуется для всех про- 
граммистов и других технических сотрудников в компании. Если вы хо- 
тите создать группу тестирования как параллельную техническую ко- 
манду, равноправную с группой разработки и другими техническими 
службами, отсутствие требования к уровню образования при условии, 
что другие группы имеют такое требование, будет тормозить достиже- 
ние этой цели. В то же время, когда мы рассматриваем эту тему при изу- 
чении курса управления тестированием, один или несколько слушате- 
лей почти всегда приводят убийственные аргументы в защиту того, что 
уровень образования не имеет значения или что тестировщик, имею- 
щий необходимый уровень образования, может не обладать ни настой- 
чивостью, ни способностью к обучению. 

Предположим, что вы решили по какой-либо причине, что тести- 
ровщики должны формально иметь образование, чтобы попасть в 
группу тестирования. Отлично, тогда каким должно быть образова- 
ние? Если вы считаете, что наибольшее значение имеет знание техно- 
логий, то вам, возможно, захочется иметь тестировщиков с образова- 
нием в области компьютерных наук или разработки программного 
обеспечения. Если вы считаете, что ключевым является знание пред- 
метной области, то, возможно, вы будете искать тестировщиков с обра- 
зованием в области администрирования бизнеса, бухгалтерского учета 
или других специфических проблем, которые помогает решать пользо- 
вателям разрабатываемая система. Если вы думаете, что наибольшее 
значение имеют навыки тестирования, то, к сожалению, ваши возмож- 
ности ограничены. Лишь немногие учебные планы специальностей 
разработки программного обеспечения и компьютерных наук начина- 
ют включать курсы тестирования (некоторые даже создают специали- 
зации, связанные с тестированием), так что число выпускников, имею- 
щих такое образование, похоже, в ближайшем будущем останется 
небольшим. 

Если требуется разностороннее образование в области компьютер- 
ных технологий, существуют другие возможности, помимо четырех- 
летних колледжей. Некоторые средние школы в Соединенных Штатах 
в настоящее время являются средними техническими учебными заве- 
дениями, включающими в программу обучения компьютерные курсы. 
Военные училища также проводят компьютерную подготовку для неко- 
торых вновь поступивших на военную службу и кадетов. Обществен- 
ные колледжи в США предоставляют двухлетнее обучение, есть также 
технические и торговые училища, которые могут дать серьезную под- 
готовку в области компьютерных технологий. 

В некоторых частях мира имеет большое значение четырехлетнее 
(и более) обучение в колледже по определенной специальности. Напри- 
мер, когда я обсуждал эту тему с моими коллегами тест-менеджерами из 
Индии, они сказали, что окончание колледжа является необходимым ус- 
ловием для приглашения на интервью, не говоря уже о работе. Аналогич- 
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но, в Японии формальное наличие образования в колледже рассматрива- 
ется как существенная часть начала карьеры. 

Независимо от того, имеет кандидат формальное образование или 
нет, обычно требуются специальная подготовка и непрерывное обуче- 
ние. Существуют различные учебные курсы, семинары и сертификацион- 
ные программы. Большое количество конференций по тестированию, 
включая консультирование и публично анонсированные обучающие ме- 
роприятия, проводятся в разных точках мира . 

Курсы и статьи, представляемые на конференциях и публично анон- 
сированных обучающих мероприятиях, проводятся ведущими практи- 
ками в области тестирования. До включения в программу конференции 
статьи проходят оценку группой экспертов. Преподаватели учебных 
курсов обычно являются авторами многочисленных публикаций, веду- 
щими консультантами или практиками с десятилетиями опыта в тести- 
ровании. 

Кроме профессиональных конференций, существует много спосо- 
бов пройти платное обучение. Обучение является во всем мире серьез- 
ным бизнесом. Находитесь ли вы в Бангоре, штат Мэн, или в Бангалоре, 
Индия, вы наверняка встретите приглашение пройти обучение и сдать 
экзамен, чтобы стать сертифицированньм инженером М!сгозой Зузіет. 
Некоторые компании, производящие инструменты тестирования, в на- 
стоящее время также предлагают обучение для получения сертифика- 
тов. Наконец, как коммерческие, так и некоммерческие организации 
предлагают пройти обучение и сдать экзамены на получение сертифика- 
тов по тестированию. 

В книге “После золотой лихорадки” (“Аўіет ће Со4 Виз") Стив Маккон- 
нел (5еуе МсСоппе|) описывает общепринятую совокупность знаний, а 
также программы сертификации, соответствующие этой совокупности 
знаний, как один из общих признаков профессии. Существует большое 
разнообразие сертификационных программ, относящихся к навыкам 
тестирования. Если вы рассматриваете одну из сертификационных про- 
грамм, советую вам задать следующие вопросы: 


и В какой степени совокупность знаний или программа курсов связа- 
нас практическим тестированием, навыками и наилучшими спосо- 
бами выполнения работ? 


и Кто разработал и поддерживает совокупность знаний или програм- 
му курсов? 
ш Каковы квалификация, опыт создателей совокупности знаний или 


курса и какова степень доверия к ним как к специалистам по тести- 
рованию? 


и Требует ли прохождение обучения для сдачи сертификационного 
экзамена (экзаменов)? Если да, то каковы квалификация, опыт соз- 


Я лично представлял и лицензировал учебные курсы по тестированию и управлению им 
в США, Канаде, Европе, на Ближнем Востоке, в Австралии, Южной и Восточной Азии. 
Я участвовал и выступал на конференциях по тестированию в США, в Европе, на Ближнем 
Востоке, в Южной Азии и в Австралии. 
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дателей учебных курсов и степень доверия к ним как к специали- 
стам по тестированию? 


и Можно ли сдать сертификационный экзамен (экзамены) по Интер- 
нету? 

и Существуют ли требования минимального опыта, необходимого 
для получения сертификата, наряду со сдачей одного или несколь- 
ких экзаменов? 


и Соответствует ли сертификационная программа какому-либо про- 
мышленному стандарту, и применим ли этот стандарт к вашей дея- 
тельности? 


и Сертификационная программа посвящена тестированию или кон- 
тролю качества? 


и Какова стоимость сертификационной программы в сравнении 
с другими программами, которые, возможно, предоставляют ана- 
логичную совокупность знаний или программу курса? 


и Необходима ли повторная сертификация или непрерывное обуче- 
ние для сохранения сертификата? Если да, каковы затраты на это? 


и В каких странах предлагается и признается данная сертификацион- 
ная программа? 


и Что думают об этой программе сертификации ваши коллеги и дру- 
гие специалисты по тестированию, мнению которых вы доверяете 
и укоторых нет других скрытых интересов? 


и Не пытается ли программа сертификации проповедовать “единст- 
венно верный путь тестирования”, чрезмерно инструктивный, 
контекстно-независимый подход? 


Среди программ сертификации есть очень неплохие, которые позво- 
ляют соискателям получить дипломы специалистов-тестировщиков. 
Есть также и плохие сертификационные программы. Права на предло- 
жение сертификации обычно не предоставляются никакой ассоциации 
или организации, за исключением самой сертифицирующей организа- 
ции. Другими словами, большинство программ сертификации могут 
быть описаны термином “бумажная сертификация” (Нах сегійсайоп). 
Они базируются только на доверии, опыте и рекомендациях, которые 
имеются у людей, участвующих в преподавании программ. Даже хоро- 
шие программы весьма различаются между собой, поэтому советую вам 
проделать подготовительную работу перед выбором сертификацион- 
ных программ. 

Помимо этих программ, некоторые из компаний-разработчиков инст- 
рументов тестирования предлагают сертифицироваться для использова- 
ния их инструментов и специальных методологий разработки, рекомен- 
дуемых ими. Однако такие программы сучетом их происхождения всегда, 
по крайней мере, воспринимаются, если не являются таковыми на самом 
деле, элементами достижения главной цели самих производителей инст- 
рументов — получения прибыли. 

Такие компании, как Сізсо и Місгоѕоќ, предлагают сертификацию 
в своих особых технологических наработках, также доступна сертифика- 
ция в таких предметных областях, как финансы и юриспруденция. Хотя 


Глава 8. Поиск искусных тестировщиков 247 


эти программы могут быть полезны при изучении технологий и предмет- 
ной области, я уверен, что тестирование программного обеспечения де- 
факто стало отдельной профессией со своими уникальными умениями 
и навыками в мире разработки систем. Компетентные тестировщики 
должны обладать этими навыками и демонстрировать мастерство владе- 
ния ими. Вероятно, через какое-то время станет доступным получение об- 
разования, соответствующего современным требованиям в области тес- 
тирования, в колледжах, профессиональных училищах или с помощью 
программ сертификации. 


Отношение к делу 


Прием на работу сотрудников связан не только с вопросами их квалифи- 
кации. Некоторые неотъемлемые черты тестировщика больше относят- 
ся к мировоззрению, нежели к навыкам. Конечно, всем известно, что оз- 
начает, когда о ком-то говорят, что у него хорошее отношение к делу. Это 
общепризнанный элемент мировоззрения профессионала. Однако для 
тестировщика важны еще некоторые черты. 

Первое, это то, что я бы назвал профессиональным пессимизмом, Это 0з- 
начает, что тестировщик подходит к решению задач тестирования с рабо- 
чим предположением, что в продукте есть ошибки и группа тестирования 
их обнаружит. Однако тестировщик должен придерживаться этой точки 
зрения ограниченно, имея в виду общее предположение о том, что каче- 
ство — это только одна из общих категорий рисков, подвергающих опас- 
ности проект. Тестировщики должны защищать качество и мнение поль- 
зователей о системе. Но они не должны это делать, выступая в качестве 
соперников программистов, выдвигая претензии личного характера или 
в неконструктивной манере. Предпочтительнее, если мы будем это де- 
лать путем, объединяющим реалии бизнеса с системной разработкой 
и сопровождением. 

Во-вторых, тестировщики должны привносить разумную любозна- 
тельность в свою работу. Чтобы найти ошибку, тестировщики должны 
быть скрупулезньми как при разработке, так и при выполнении тестовых 
сценариев. Отсутствие любознательности ведет к небрежности в тесто- 
вых сценариях, которые не проверяют наиболее укромные уголки и тре- 
щины в системе, являющиеся потенциальными источниками ошибок. 
Отсутствие любопытства приводит к появлению отчетов о дефектах, ко- 
торые не связаны со сбоєм, наблюдаемым с точки зрения пользователя. 
Однако важно соблюдать разумный баланс, поскольку приходится писать 
и выполнять большое число тестов в рамках ограниченных ресурсов 
и времени. Тестировщик должен всегда задаваться вопросом: “Сколько 
усилий потребуется для решения данной задачи?" 

Третье, также относящееся к разумному балансу, — это способность 
концентрироваться. Под ней я подразумеваю понимание ключевых при- 
оритетов и нацеливание тестирования на следование им. Это трудно сде- 
лать, поскольку приоритеты часто меняются. (Конечно, тест-менеджер 
должен обсуждать приоритеты и причины, по которым они меняются, с 
инженерами-тестировщиками и младшими тестировщиками.) Я знаю тес- 
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тировщиков, которые из-за неспособности концентрировать свое внима- 
ние испытывали трудности в выполнении поставленных перед ними за- 
дач на должном уровне качества и в надлежащие сроки. Хотя они 
обладали хорошими знаниями в тестировании, этот единственный про- 
бел в их характере ограничил их потенциал. 

В четвертых, тестировщик должен иметь желание выполнять обоб- 
щающую и вспомогательную работу, нацеленную на устойчивый, надеж- 
ный процесс, а не на поиск славы или магического разрешения проблем 
посредством личного героизма. Даже в хороших компаниях, которые 
предоставляют широкие возможности для развития карьеры тестиров- 
щиков и способствуют формированию равных отношений с коллегами из 
других подразделений, тестирование иногда рассматривается как работа 
с множеством нежелательных свойств. Например, группа тестирования 
выходит на первый план непосредственно в конце проекта, когда стано- 
вится очевидным чрезмерный оптимизм при подготовке планов проекта, 
проявляющийся в ошибочных сроках и перерасходе бюджета. Другим 
примером является то, что тестировщики должны сообщать плохие ново- 
сти группе разработки. Не имеет значения, насколько преуспевает тести- 
ровщик в дипломатии и общении. Он время от времени сталкивается с со- 
противлением и защитной реакцией, выступая в роли гонца с плохой 
новостью. Оба этих явления порождают дополнительные стрессы в жиз- 
ни тестировщиков. Хорошие тестировщики заставляют себя работать 
в условиях недооценки и плохого понимания их роли со стороны других 
участников проекта. 

В-пятых, тестировщики должны быть готовы к напряженной работе, 
поскольку главное внимание на них обращено в конце проекта, когда на- 
рушаются сроки, испаряется бюджет, растет раздражительность и увели- 
чивается давление с тем, чтобы бросить дополнительные усилия на про- 
ект, причем особенно возрастает давление на группу тестирования. 
В этом нет никакого рационального смысла. Например, в одном из проек- 
тов я работал с менеджером разработки, который делал оскорбительные 
замечания по поводу того, что группа тестирования не работает по 16 ча- 
сов в день, как программисты. Я сказал контактному лицу заказчика, что, 
поскольку сотни ошибок стоят в очереди в системе управления дефекта- 
ми, ожидая исправления, группа тестирования не является узким местом 
проекта. Тем не менее все закончилось введением ночной смены и выпол- 
нением тестов семь дней в неделю, чтобы устранить ощущение того, что 
группа тестирования неким таинственным образом не выполняет свою 
часть работы. 

Шестое и последнее — тестировщики должны стремиться отстаивать 
и защищать качество разумно и в пределах бизнес-контекста, но делать 
это твердо и убедительно. Если тестировщик готовит отчет об ошибке, 
который не нравится разработчику, и сталкивается с противостоянием 
“несчастного” программиста, ему не нужно склонять голову, класть руки в 
карманы и смиренно бормотать: “Хорошо-хорошо, я думаю, что отзову 
этот отчет об ошибке”. 

Вместо этого тестировщик должен выпрямить спину, выслушать аргу- 
менты программиста и затем сказать что-то вроде этого: “Да, но если бы 
я был заказчиком и увидел такое поведение ‘системы, у меня не было бы 
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поводов для восторга. Возможно, я создаю проблему на ровном месте, по- 
этому мы можем поручить принять решение по этой ошибке комитету по 
контролю о внесении изменений (или комитету по управлению дефекта- 

`ми) на следующем совещании”. Твердый, но гибкий характер является 
требованием к хорошему тестировщику. 


По ту сторону очевидных вопросов 
в ходе интервью 


Одним изаспектов уникальных навыков тестировщиков (что нередко 
игнорируется) является то, что интервью с ними нельзя проводить 
так же, как мы проводим интервью с разработчиками. О собеседова- 
ниях с программистами при приеме на работу написано много литера- 
туры. Атағоп.сот дает обзор списка рекомендованных книг об ин- 
тервью с кандидатами на должность разработчика программного 
обеспечения. 

Тем не менее навыки программирования — несущественный, а в неко- 
торых случаях даже ненужный элемент квалификации специалиста- 
тестировщика. Я бы порекомендовал несколько вопросов, которые выхо- 
дят за рамки стандартных вопросов типа: “Напишите мне программу, ко- 
торая копирует файл...” или “Опишите проблемы в своем развитии карье- 
ры и как вы их решали”. 


= Ожидали ли вы или нет в своем последнем проекте, что тесты прой- 
дут без ошибок? Почему? Будет ли, по вашему мнению, обстоять 
иначе в текущем проекте? Почему? 


и Приведите примеры тестовых сценариев из недавно выполненных 
вами, про которые вы с уверенностью могли сказать, что с их помо- 
щью будут обнаружены ошибки. Как вы об этом узнали? Как вы про- 
веряли ожидаемые результаты? 


м Когда вы в последний раз писали отчет об ошибке, какой способ 
и какую тональность вы использовали при обсуждении ошибки с со- 
трудниками группы разработки? Удовлетворил ли вас результат об- 
суждения? Расскажите о моменте, когда вы сообщили об ошибке 
и почувствовали, что ваши манера и тон способствуют эффектив- 
ному обсуждению. 


и Расскажите о случае, когда вы были убеждены, что обнаруженная 
вами проблема окажет негативное влияние на мнение пользовате- 
лей о системе, но с вами не все были согласны. Удалось ли вам раз- 
веять сомнения и отстоять отчет об ошибке, или это не входило 
в ваши обязанности? 


и Расскажите о ваших проектах, тестирование в которых доставляло 
удовольствие и было интересным. Какие его части были приятны- 
ми и интересными? Какие части тестирования не были приятными 
или интересными? Расскажите о проектах тестирования с вашим 
участием, в которых небыло ничего интересного. Почему, по ваше- 
мумнению, так произошло? 
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ш Расскажите о случаях, когда вам удавалось не соглашаться, не стано- 
вясь неприятным для собеседников. Что вы можете сказать о случа- 
ях, когда добиться этого не удавалось? 


и Работая здесь, нужно будет отслеживать множество тестовых сце- 
нариев, тестовых данных, вариантов тестовой среды, тестовых 
версий, отчетов о дефектах (добавьте все, что имеет отношение 
к вашей ситуации). Состояние каждого элемента может меняться 
ежедневно. Расскажите, как вы будете управлять таким большим 
множеством непрерывно меняющихся объектов. 


ш Иногда эта должность может повлечь за собой 60-часовую рабочую 
неделю /занятость в некоторые выходные/вечерние смены (что 
применимо к вашей компании). Вы можете работать по такому гра- 
фику? Приведите пример из прошлого опыта, когда вы работали та- 
ким образом. Что происходило, когда вы переутомлялись? Как вы 
боролись с этой проблемой? 


ш Расскажите о последнем случае, когда вы боролись за разумное вы- 
деление времени, необходимое на написание тестового сценария. 
Что вы можете сказать по поводу разумного выделения времени на 
локализацию дефекта? Если вам поручено выполнять шесть тестов 
в день, а второй позволил обнаружить ошибку, как вы определите, 
стоит ли рискнуть завершить четыре оставшихся теста, чтобы ис- 
следовать найденную ошибку? 


ш Расскажите, какие виды информации ваши менеджеры предостав- 
ляли вам и как вы использовали полученную информацию для со- 
хранения правильного направления движения. Были ли случаи, ко- 
гда информация не доходила и вы не понимали смысл? 


и Как вы планируете применить то, чему научились в ходе (некото- 
рых ранее выполненных) проектов, для тестирования нашего про- 
дукта? Какое поведение и какие действия из тех, что вы выполняли 
в предыдущих проектах, вы не будете повторять сейчас? 


и Почему вам нравится тестирование? Каковы ваши карьерные пла- 
ны? Предполагаете ли вы продолжить карьеру в качестве тести- 
ровщика? Чем вы планируете заниматься через пять лет? Какое 
место вы отводите тестированию как специализации в ближай- 
щие пять лет? 


Можно задавать и много других вопросов, но главное — понять основ- 
ную идею. Быть хорошим тестировщиком — это больше, чем просто 
иметь набор навыков и подходящее образование. Быть хорошим тести- 
ровщиком, значит обладать также соответствующим отношением к делу, 
темпераментом и мировоззрением. Вероятно, нужно соответствующим 
образом организовать процесс интервью. 


\ Дополнительные идеи по поиску, интервьюированию и приему сотрудников на работу 
можно найти в статье Сема Канера (Сет Капег) “Кеспийпя бойжаге Теѕќегѕ” по адресу 
уим.затараапе.сот и в справочнике Джоанны Ротман (Јоһаппа Коштап) “Нігіпр 
Тесіпіса! Реоріє", доступном на мии готап.сота. 
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ап в процессе раї ит потре 
в самом начале процесса подбора сотрудников, и вы сэкономите время 


- є Сколько времени в среднем нужно, чтоб выполнить тесты? 


Изучите и проранжируйте резюме. (Хороший способ сэкономить вре- 
мя и деньги — завести папку для хранения резюме тех людей, которые не 
подходят на данную позицию, но являются первоклассными специалиста- 
ми. Позвоните или напишите им электронные письма, когда у вас будут 
подходящие вакансии.) Не забудьте проверить те навыки и знания, кото- 
рые подходят для разных специальностей. Проведите телефонные ин- 
тервью с основными кандидатами. Это позволит понять, насколько они 
правдивы, когда говорят о своих умениях и навыках, и насколько подхо- 
дят для занятия вакансии. После телефонных интервью снова проранжи- 
руйте кандидатов и пригласите основных из них на интервью. Если вы 
планируете проводить для них испытания, предупредите их об этом. 

Проводите интервью в обстановке, максимально удобной для того, 
чтобы получить больше открытых и честных ответов. Нужно задать кан- 
дидатам все обычные вопросы (об их сильных сторонах, чему они хотели 
бы научиться, о прошлом опыте и т.д.). Свободная форма вопросов даст 
возможность кандидатам сказать все, что нужно. Поощряйте их задавать 
вопросы: люди, которые задают вопросы, обычно хорошо проявляют 
себя в тестировании. Подготовьте вопросы, которые помогут оценить их 
способности или навыки в расстановке приоритетов, решении проблем, 
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управлении временем, оценить организованность, аналитические спо- 
собности, умение работать в команде, документировать, общаться, дово- 
дить дело до конца, давать представления на концептуальном уровне, сле- 
довать указаниям, ориентироваться в деталях, оценить гибкость, 
производительность в условиях стресса и определить наличие целей 
и мотивации. Подготовьте специальные вопросы для каждого этапа ин- 
тервью: телефонного интервью, группового интервью или интервью 
с коллегами, интервью с менеджером. 


От увеличения группы к росту квалификации 


До сих пор я в основном рассматривал процесс подбора кадров, а также 
включение новых тестировщиков в группу тестирования. Конечно, это 
важная часть увеличения группы тестирования. Работа нуждается в ис- 
полнителях, и мы должны найти нужных людей для задач, решать кото- 
рые придется в ближайшем будущем. 

Тем не менее большинство специалистов не хотят просто ходить на ра- 
боту и делать каждый раз одно и то же, ничему не обучаясь и применяя 
только существующие навыки. Профессионалы хотят двигаться по пути 
развития карьеры, что означает рост квалификации. Кроме того, совокуп- 
ность навыков, необходимых для группы тестирования, находится в посто- 
янной динамике. Расширение перечня задач группы тестирования, новые 
технологии и новые продукты требуют новых навыков группы тестирова- 
ния, В следующей главе мы посмотрим, как можно управлять этой частью 
процесса создания группы, стимулируя рост квалификации и развитие 
карьеры сотрудников группы. После этого мы вернемся к процессу созда- 
ния группы тестирования, чтобы определить параметры качественного 
процесса, найти решение неизбежных проблем и внедрить усовершенст- 
вования процесса. 


ГЛАВА 9 


Подготовка превосходной группы 
тестирования: навыки, 
отношение к делу и пути 
развития карьеры 


В предыдущей главе я описал первую часть процесса создания группы 
тестирования, рассмотрев вопросы, связанные с подбором кадров. 
Очевидно, что для создания сильной команды тестирования очень важен 
подбор подходящего коллектива сотрудников. Тем не менее существует 
также долгосрочный аспект построения группы, связанный с обучением. 
Чтобы получить грамотный, законченный процесс, мы должны уделить 
внимание этому аспекту. Позвольте посвятить несколько страниц второй 
части процесса построения группы тестирования, а затем мы вновь рас- 
смотрим весь процесс для завершения темы. 


Джамал и Лин Цу обсуждают вопросы 
повышения квалификации 


Сентябрь был трудным месяцем для Джамала. Он не только готовил пла- 
ны для проекта “Суматра”, но также руководил тестированием версии со- 
провождения для двух других продуктов пакета ОЁНсеАггом и искал пять 
новых тестировщиков. Кроме того, все нынешние сотрудники его груп- 
пы проходили ежеквартальную аттестацию роста квалификации. Джамал 
отнесся серьезно к этой обязанности, поскольку он знал, что долгосроч- 
ная жизнеспособность его группы тестирования, а также лояльность его 
сотрудников существенно зависят от возможностей развития карьеры ка- 
ждого из них. Таким образом, он провел в офисе всю вторую половину 
дня субботы, 21 сентября, за изучением таблицы контроля навыков 
и в размышлениях о том, что нужно сделать. Он отправил результаты 
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оценки всем членам группы тестирования, сопроводив их следующим 
письмом. 


Привет всем! 


К письму прикреплена таблица оценки навыков. Таблица с названием 
"Управление навыками (502)” содержит краткий перечень навыков на на- 
стоящий момент. 


Изучив эту таблицу, я обнаружил, что наиболее слабым местом является 
для нас знание предметной области, особенно текстовых процессоров, ра- 
ботающих в средах, отличных от Мілпбомѕ. Я думаю, что в ближайшие месяцы 
это может стать проблемой, особенно для ручного тестирования. 


Также, хотя в целом мы сильны в тестировании, есть ряд недостатков 
в области автоматизированного тестирования, на которые я бы хотел обра- 
тить внимание - это тестирование надежности и комплексное тестирование. 


Прошу вас потратить немного времени в ближайшие два дня на размышления 
о разделах, в которых вы хотели бы улучшить свои навыки, имея в виду 
упомянутые выше требования, предъявляемые к группе тестирования. Я на- 
значу встречи с каждым из вас на следующей неделе, чтобы подготовить 
планы повышения квалификации. 


С уважением, 


Джамал 


Джамал решил начать с Эммы и Лин Цу, поскольку ему хотелось, что- 
бы они сразу же приступили к освоению новых навыков, которые им по- 
требуются в проекте “Суматра”. Во вторник, 24 сентября, Лин Цу и Джа- 
мал провели получасовую встречу в его кабинете. После пары минут 
светской беседы Джамал перешел к делу. 

“Итак, Лин Цу, что ты думаешь о повышении квалификации в следую- 
щем квартале?” 

“Ты знаешь, что я хочу приобрести болыше опыта за пределами 
Удадомз, но технологии не являются для нас слабым местом. Тем не ме- 
нее, что ты думаешь об этом? Если судить по твоему письму, мне кажется, 
что я бы смогла поработать над улучшением знаний в предметной облас- 
ти, а именно в обработке текстов и управлении документооборотом, 
включая платформы Мас и ОМІХ.” 

“Было бы отлично. Я рассчитывал услышать от тебя что-то подоб- 
ное, — сказал ободряюще Джамал. — Есть ли какие-то идеи, как это сде- 
лать?” 

“Да, тут через несколько недель будет конференция, посвященная 
управлению документооборотом, — ответила Лин Цу. — Предлагаются два 
учебных курса в ходе конференции, что также кажется полезным”. Она 
передала Джамалу объявление о конференции. 

Джамал изучил его, одобрительно мыча. Наконец, он поднял глаза 
и сказал: “Да, было бы отлично. Знаешь, вообще-то все мы можем посе- 
тить только две конференции или пройти два вида обучения в течение 
финансового года. Ты уверена, что это один из двух возможных случаев, 
которые ты хотела бы использовать?” 
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“Да, по двум причинам, — ответила она. — Первая — это нужное обуче- 
ние в нужное время. Вторая — конференция будет в Сан-Диего, где живут 
мой брат и невестка...” | 

“О!” — воскликнул Джамал. 

“Я бы хотела уехать в ночь на пятницу, взяв день в счет отпуска, и про- 
вести там целую неделю”. 

“Хм, — произнес Джамал. — Сможем ли мы дать тебе один день в счет 
отпуска непосредственно перед конференцией? У нас много дел в проек- 
те “Суматра”. Боюсь, что десять дней подряд приведут к отсрочке каких- 
то дел, и это может потом негативно сказаться на работе”. 

“Но я сэкономлю компании кучу денег на командировке. Сюда попада- 
ет уикенд, и надо учесть тот факт, что я остановлюсь у моего брата, а не 
в отеле”. 

Джамал сел и на минуту задумался. “У ее плана есть преимущества, — 
признался он сам себе, — и, вероятно, нечестно мелочиться из-за одного 
дня в этих обстоятельствах. Конечно, получится больше, чем один день, 
поскольку она наверняка уйдет рано в четверг, чтобы успеть на самолет. 
Но для компании хорошо, если удастся сэкономить деньги”. 

“Хорошо, — сказал Джамал. — Давай заключим сделку. Ты уедешь 
в четверг вечером, а я не буду считать пятницу днем отпуска, назовем ее 
днем отгула, если ты вернешься в пятницу вечером, а в субботу вый- 
дешь на работу, чтобы наверстать упущенное. Я буду тоже работать 
с тобой”. 

“Согласна”, — улыбнулась Лин Цу. 

“Итак, как насчет способов применения всех тех знаний, которые ты 
собираешься усвоить?” — спросил Джамал. 

Джамал и Лин Цу продолжили обсуждение способов применения полу- 
ченных навыков в тестировании. Лин Цу предложила несколько специ- 
альных тестов, которые она запланировала разработать и выполнить. 
Джамал заметил, что Динеш Кумар, новый инженер-тестировщик, кото- 
рый приступит к работе через две недели, хорошо знает области, о кото- 
рых она говорила. 

“Если ты не против, — сказал Джамал. - Я попрошу Динеша проверить 
твои тесты. Таким способом он сможет передать тебе часть знаний”. 

“Это было бы отлично. С помощью этого плана, — резюмировала Лин 
Цу, — я должна достичь уровня между двойкой и тройкой для каждого из 
четырех навыков в области текстовых процессоров и управления доку- 
ментооборотом для систем Мас и СМІХ". 

“Отлично. Давай определим цель: повысить уровень владения навы- 
ками на единицу в этих областях в таблице управления навыками. Мы 
оба можем быть приятно удивлены, если ты добъешься большего. Со- 
гласна?” 

“Здорово!” 

“Это позволит тебе опередить график, когда мы будем проводить в ян- 
варе ежегодную аттестацию. Также, Лин Цу, начинай думать о ежегодной 
аттестации, чтобы можно было определить для тебя более высокие цели 
в следующем году. Я в самом деле доволен твоим ростом в профессиональ- 
ном плане, поэтому я бы хотел чацелить тебя на повышение на следую- 
щий год”. 
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№ этапа Этап Выполнено? 


2. Стимулировать повышение квалификации и карьерный рост М 
сотрудников группы. 


2.А. Совместно с новыми сотрудниками разработать пути разви- м 
тия их карьеры. 


2.В На регулярной основе проверять пути развития карьеры всех М 
сотрудников и отмечать прогресс каждого. 


2.С Активно управлять процессом овладения сотрудниками навы- М 
ками, которые требуются для достижения целей как сотрудни- 
ка, так и всей группы тестирования. 


Оценка навыков как инструмент управления 
карьерным ростом группы тестирования 


В предыдущей главе было показано, как таблица оценки навыков стано- 
вится полезным инструментом поиска новых сотрудников для любой 
группы тестирования, большой или маленькой, специальной или одно- 
родной, нацеленной на реализацию конкретного проекта или на наличие 
определенной совокупности навыков. Можно использовать эту таблицу 
и для поиска существующих слабых мест в группе тестирования и для 
приема новых сотрудников с целью ликвидации этих мест. Имея резюме 
кандидатов, можно также применять таблицу навыков для их отбора, а за- 
тем на ее основе нацеливать вопросы интервью на исследование опреде- 
ленных разделов знаний, которые вы пытаетесь добавить к тем, которы- 
ми уже владеет группа тестирования. 

Как вы уже видели из разговора Джамала и Лин Цу, таблица оценки на- 
выков также является мощным средством для управления развитием 
карьеры и совокупности навыков группы тестирования. В перечне долж- 
ностных обязанностей, представленном на рис. 9.3, одним из требований 
является “участие сотрудника в ежеквартальной аттестации ключевых на- 
выков группы тестирования совместно с тест-менеджером, ежекварталь- 
ное определение целей развития навыков в трех, как минимум, разделах 
путем внутреннего (взаимного) и внешнего (семинары/учебные кур- 
сы/конференции) обучения и их успешное достижение”. 

Тест-менеджер вместе с каждым сотрудником должны регулярно обсу- 
ждать и выбирать разделы, в которых сотрудник может повысить квали- 
фикацию. Как правило, тест-менеджер имеет список разделов, в которых 
он хочет улучшить навыки группы в целом, как это было у Джамала, а со- 
трудники знают, в каких разделах они хотят повысить квалификацию, 
чтобы продвигаться по выбранному пути развития карьеры. С помощью 
целевого поручения определенных задач, наставничества и внешнего 
обучения квалификация сотрудников группы тестирования может непре- 
рывно расти и развиваться. 

Это не только на пользу группе тестирования. Чтобы способствовать 
карьерному росту сотрудников группы тестирования, тест-менеджер дол- 
жен оказывать им помощь в приобретении навыков и опыта, которые 
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Таблица! ключевых навыков: открытая регистрация 


ра кадро І 
это открыто рти словами, а 
‚навыков других ‘сотрудников груп 
и: такой В Ві 


заны их развития. А . 
В вжоторой люди честно м открыто го: 
56 і 


утверждение еи но другие сотрудники группы это заметят. ао я 
говорю об этом сотрудникам, когда рассказываю о процессе самостоятель- 
‘ной оценки навыков; в особенности, если я чувствую, что они могут поддать- 
ся искушению сообщить о себе более выгодную, но неточную информацию... 
Если вы решили: сделать эту информацию открытой, УАВ что нужно. 
‘учесть два момента: 
1. Не ‘используйте этот процесс и полученную информацию. в качестве. 
сти процесса ежегодной аттестации или повышения зарплаты 
асается групп, которыми я руковожу, единственным оне 


і целью ежегодной аттестации. Это означает, что ция ох обуправ- 
‚о лений повышением в компании не является частью ежегодной аттеста- 
ции кого бы то ни было и, следовательно, не является конфиденциаль-. 
ной. Если по какой-то причине вы приняли. решение использовать 
данные непосредственно, например, в качестве одной из целей еже- 
. годной аттестации “Увеличить на пять рейтинг навыков в каждом из 
‘трех основных разделов", то оценки навыков. должны быть конинено, 

- 2 циальными личными данными". 


2. Не давайте доступ к зтой информации вашему. руководству и вашим 
-коллегам-менеджерам, если вам кажется, что они воспользуются ею 
_ в качестве инструмента для продвижения по карьерной лестнице, 
увольнения или перевода лучших сотрудников из группы тестирова- 
ния. Я не распространяю эту информацию за пределы группы тестиро- 
ания, если стандартом компании не является обратное, и в этом слу- 
чав. информация обо всех группах доступна всем желающим. | 
Таков мой подход, и некоторые говорили, что он весьма радик 
Если вы рецили. внедрить. его в свою практику, ем НО 3 


о в компа! ми, к какую РИС. вы имеете право обі бю ИК: 
‘необходим мо ‘обращаться с полученной нформацией. | 


Некоторые компании проводят исследование навыков сотрудников только в качестве 
части ежег ОДНОЙ аттестации, Я думаю, что зто слишком редко, поскольку совершенствова- 
ние навыков сотрудников в целях совершенствования возможностей групны должно осуще- 
ствляться постоянно. Кроме того, существует риск увязывания процесса совершенствова- 
ния навыков, проводимого таким образом, с оценкой производительности, поскольку 
может оказаться довольно трудным делом отделить оценку и премии сотрудника от числен- 
ного повышения его рейтинга навыков. Любая привязка, явная или на уровне восприятия, 
может привести к искусственному увеличению уровня навыков, достигнутого сотрудника- 
ми, что снижает ценность процесса повышения квалификации. 
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необходимы для решения проблем, связанных с их новым назначением. 
Это может быть новая роль внутри группы тестирования, например, 
всвязи с повышением с должности младшего тестировщика на должность 
инженера-тестировщика, это может быть новая должность где-то еще в 
компании, например, в связи с переходом с должности ведущего инжене- 
ра-тестировщика на должность менеджера сетевой системы поддержки 
пользователей. Таким образом, тест-менеджер и все сотрудники группы 
тестирования должны совместно работать для синхронизации процесса 
совершенствования навыков с направлением развития карьеры каждого 
сотрудника. 


Построение успешного процесса создания 
группы тестирования 


Мы рассмотрели весь процесс создания группы тестирования, поэтому 
предлагаю обсудить, что дает группе тестирования и принимаемому кан- 
дидату хороший процесс создания группы тестирования. 


Применение философии “выигрывают обе стороны” 


При поиске новых сотрудников вы стремитесь отобрать лучших людей из 
пула кандидатов, тех, кто имеет наилучшую квалификацию, чтобы по- 
мочь проверить качество продукта и способствовать достижению более 
масштабной цели — управлению рисками качества продукта. Если эти 
люди выбирают карьеру в вашей компании, вы, вероятно, будете способ- 
ствовать их продвижению по карьерному пути, что ставит перед тести- 
ровщиками более серьезные цели, способствует непрерывному росту 
производительности и эффективности группы тестирования. Если вы 
сами выступаете в роли кандидата, вам хочется найти наиболее подходя- 
щую работу для данного этапа развития карьеры и знать, что данная рабо- 
та будет способствовать продвижению по выбранному карьерному пути. 

Смысл философии “выигрывают обе стороны” при подборе кадров со- 
стоит в том, что обе стороны, работодатели и работники, приобретают 
от взаимоотношений каждого работника с работодателем. Эти приобре- 
тения могут быть как долгосрочными, так и краткосрочными. К. сожале- 
нию, некоторые менеджеры по подбору персонала, особенно в сложные 
времена для экономики, подходят к поиску сотрудников и работают в со- 
ответствии с правилами игры с нулевой суммой, (например, шахматы или 
покер), игры, в которой есть победитель и побежденный. В играх с нуле- 
вой суммой одна сторона может выиграть только в случае поражения дру- 
гих сторон. Процветающее предприятие, созданное квалифицированны- 
ми менеджерами, не играет в игры с нулевой суммой. На процветающем 
предприятии создается богатство, приобретаются знания, а жизнь каж- 
дого сотрудника наполняется ощущением успеха. 

С помощью процесса создания команды один кандидат выбирает и 
выбирается на ранее открытую вакансию, а другие кандидаты отверга- 
ются или не получают предложений. Взаимное удовлетворение целей 
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всех сторон, включая тех, кого не принимают на работу, может иметь 
место, когда 


ш Мы привлекаем подходящих кандидатов. 
м Мы отвергаем неподходящих кандидатов. 


ж Мы делаем предложения одному или нескольким кандидатам, обла- 
дающим надлежащей квалификацией. 


ш Выбранные кандидаты получают точную информацию, на основе 
которой принимают решение принять или отклонить сделанные 
предложения. 


Этот процесс показан на рис. 9.1. 


ба <-- 
№ 


Джамал Браун 
тест-менеджер 


Новый кандидат СМ А КЕЕ. 
Группа тестирования 


Рис. 91. От кандидата к сотруднику 


На качество этого процесса влияют различные факторы и свойства 
взависимости от того, чьими глазами вы смотрите на процесс: кандидата, 
работодателя или работника. С точки зрения кандидата или работника, 
главными вопросами являются следующие: “Это подходящая работа для 
меня? Удастся ли мне получить стимулы, опыт и освоить новые навыки, 
необходимые мне на этой работе, чтобы получить работу, которую мне 
захочется иметь потом?” Работодатель, в свою очередь, задается следую- 
щими вопросами: “Является ли этот кандидат подходящим для данной ра- 
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боты тестировщика? Способен ли этот человек совершенствовать свои 
навыки, чтобы помочь нам в решении новых задач?” 

Определяя процесс построения команды, мы стремимся получить высо- 
кокачественный процесс для всех участников, поскольку, в отличие от поке- 
раи шахмат, быть частью команды — не игра с нулевой суммой. Обе стороны 
хотят принять решение на основе полной информации и верных критери- 
ев. Процесс, не позволяющий какой-либо стороне получить полную инфор- 
мацию, может привести к одному или двум отрицательным последствиям: 


1. Кандидат получает работу, о которой он позже сожалеет, что ведет 
к раздражению и, вероятно, непродуктивной работе. 


2. Тест-менеджер делает предложение кандидату, о чем он впоследст- 
вии сожалеет, что ведет к корректирующим действиям с его сторо- 
ны. Действия по коррекции отношения к делу и поведения сотруд- 
ника даже в случае успеха отвлекают внимание тест-менеджера. 


Если проблемы остаются нерешенными, сотрудник либо покидает 
компанию со всеми вытекающими последствиями (текучесть кадров) 
либо продолжает работать недостаточно производительно, и, вероятно, 
возникнут проблемы с отношением к делу и увольнением. Лучшее, что мо- 
жет произойти с непрозрачным процессом, это если каждая сторона слу- 
чайно найдет верное решение, что делает подход слишком непредсказуе- 
мым для столь критичных решений. 

Грамотный процесс создания команды, связанный с выгодой для обе- 
их сторон, участвующих в нем, проявляется в предоставлении всей необ- 
ходимой информации. Следующие несколько разделов будут посвящены 
важным элементам информации как для новых сотрудников, так и для на- 
нимающей компании. Однако также верно, что имеет значение отноше- 
ние к делу и выбор философии. Компании, которые пытаются воспользо- 
ваться преимуществом работодателя с помощью вводящих в заблуждение 
и нечестных методов найма сотрудников, фиксирующие низкие зарпла- 
ты в периоды рецессий и использующие другие порочные тактические 
методы, часто пожинают плоды в виде недостаточной лояльности сотруд- 
ников и групп, которые не сделают ничего лишнего, когда компании по- 
требуется напряжение сил для достижения цели. Кандидаты, пытающие- 
ся получить работу, в которой они не являются специалистами, которые 
обманывают в своих резюме, которые не желают согласовывать совер- 
шенствование навыков с потребностями компании, часто заканчивают 
увольнением или застревают на неудовлетворяющих их позициях. Обе 
стороны, работодатель и работник, должны включаться в процесс созда- 
ния команды с готовностью помогать друг другу. 


Четкое определение должностных обязанностей 


Взаимопомощь может иметь место только в том случае, когда обе сторо- 
ны приходят кединому мнению по поводу того, какие услуги должен пре- 
доставлять работник. При отсутствии четко определенных ожиданий ра- 
ботодателя, работник только по случайности может выполнить свои 
обязанности, а работодатель не способен беспристрастно оценить каче- 
ство его работы. Сучетом основной цели группы тестирования мы можем 
определить, каким образом каждая вакансия позволяет достичь эту цель. 
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Определение должностных обязанностей должно быть дано с той степе- 
нью детализации, которая позволяет четко зафиксировать наши ожида- 
ния от работника и вто же время допускает свободу действий и индивиду- 
альную оценку специалиста, соответствующую уровню работника. 

Описание должностных обязанностей обычно соответствует катего- 
риям вакансий, влияние на которые оказывают навыки, образование, 
опыт и специализация. Обычно вакансии, открытые на низшем уровне, 
не требующие окончания колледжа или большого опыта, я называю млад- 
шими тестировщиками. 

Поскольку эти роли не предполагают наличия большого опыта, у них нет 
больших возможностей для специализации. На более высоких уровнях обыч- 
но я даю следующие наименования вакансиям: инженер по ручному тестиро- 
ванию, инженер по автоматизированному тестированию, программист- 
тестировщик и администратор тестовой среды. В группы тестирования, в ко- 
торых требуется высокий уровень знания предметной области, можно также 
включить бизнес-аналитиков или экспертов в предметной области. Налюбом 
уровне, как только сотрудники овладевают новыми навыками, слово “веду- 
щий” может быть добавлено к наименованию их специальности, а младшие 
тестировщики могут становиться инженерами, программистами-тестиров- 
щиками или администраторами среды. 

Если опираться на уровень детализации, который я поддерживаю, пе- 
речень должностных обязанностей, приведенный на рис. 9.2, не является 
адекватным. Он подходит для объявления в целях получения резюме или 
составления списка кандидатов, но настоящее описание должностных 
обязанностей, например, для письма с предложением о занятии вакант- 
ной должности, для личного дела или элемента ежегодной аттестации со- 
трудника, должно выглядеть примерно так, как показано на рис. 9.3. 

Хотя важно прояснить ожидания работодателя, мы должны помнить, 
что точные способы количественной оценки должностей, навыков и обя- 
занностей могут создать иллюзию контроля, которая не соответствует ре- 
альности. Одна менеджер, с которой я обсуждал этот вопрос, поделилась 
со мной, что она и ее непосредственный руководитель после принятия 
точного, основанного на метриках способах измерения производитель- 
ности и способностей работника, решили протестировать его перед при- 
менением. Они обсудили заранее, не заглядывая в метрики, сколько 
очков наберет каждый сотрудник. Затем они провели измерения и, вни- 
мание! Каждый набрал примерно столько, сколько они ожидали. Они 
пришли к двум выводам: 1) они подогнали результаты под ожидаемые 
цифры; 2) эти измерения — один из ложных путей рационализации того, 
что они итакуже знали. Мы можем и должны стараться получить как мож- 
но более объективный процесс, но мы не можем устранить субъектив- 
ность из процесса оценки кандидатов и сотрудников. Честно умерьте 
любые попытки строгого определения должностных обязанностей тес- 
тировщика с учетом того, что мы не готовим программу для машины, 
а описываем наши ожидания для человека. 


х Для более подробного изучения вопросов управления персоналом посмотрите "Итятр 
аї Ртојесі Мапаретепі" Роберта Гилбрета (Кобег СИБгеа!®) мли “Тйе Ассійепіа! Рғојесі Мапареї" 
Патрисии Знсворт (Раггісіа Епѕмопћ). 
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Должность: 
Назначение: 


Должность: 
Назначение: 


Должность: 
Назначение: 


Должность: 
Назначение: 


Должность: 
Назначение: 


Часть 1. Подготовка 


Инженер по ручному тестированию 


Разработка и выполнение ручных тестовых сценариев 
в соответствии с промышленными стандартами и со 
стандартами компании. 


Разработка и сопровождение инструментов отслеживания 
хода тестирования. 


Выполнение при необходимости других обязанностей, 
связанных с тестированием. 


Инженер по автоматизированному тестированию 
Участие в процессе отбора инструментов 
автоматизированного тестирования. 


Разработка и выполнение автоматизированных тестовых 
сценариев с использованием промышленных инструментов 
тестирования и инструментов внутреннего производства. 


Интеграция тестовых сценариев в систему управления 
тестами и тестовые драйверы собственного производства. 


Выполнение при необходимости других обязанностей, 
связанных с тестированием. 


Программист-тестировщик 
Разработка инструментов автоматизированного 


тестирования для программных (АРІ) и графических (001) 
интерфейсов приложений. 

Поддержка и учет затрат на разработку инструментов 
модульного тестирования. 

Выполнение при необходимости других обязанностей, 
связанных с тестированием. 


Администратор тестовой среды 


Выбор, установка и настройка тестовой сети, тестовых 
серверов, тестовых рабочих станций и тестовых баз данных 
(т.е. тестовой среды). 

Установка очередных тестовых версий в тестовой среде 

в соответствии с требованиями для поддержки процесса 
тестирования. 

Выполнение при необходимости других обязанностей, 
связанных с тестированием. 


Младший тестировщик 

Выполнение ручных и автоматизированных тестов. 
Подготовка отчетов о ходе тестирования и о дефектах для 
инженеров-тестировщиков. 

Выполнение при необходимости других обязанностей, 
связанных с тестированием. 


Рис. 9.2. Наименования должностей и роли тестировщиков 
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Должность: Инженер по автоматизированному тестированию 


Подчиняется: Тест-менеджеру 

Назначение: Участие в процессе отбора инструментов автоматизированного тестирования. 
Разработка и выполнение автоматизированных тестовых сценариев 
с использованием промышленных инструментов тестирования и инструментов 
внутреннего производства. 
Интеграция тестовых сценариев в систему управления тестами и тестовые 
драйверы собственного производства. 
Выполнение при необходимости других обязанностей, связанных 
с тестированием. 


Обязанности 
А. Технические 


• Проводить рецензирование требований, спецификаций, пользовательской документа- 
ции, файлов помощи и другой проектной документации для проверки качества разраба- 
тываемых продуктов и тестов, т.е. проводить статическое тестирование вручную. 


• Выбирать и разрабатывать надлежащие инструменты автоматизированного тестирова- 
ния, применяя самые современные методы автоматизации тестирования, например тес- 
тирование, управляемое данными. 

» Использовать методы на основе рисков для разработки, сопровождения и выполнения 
автоматизированных тестовых сценариев для различных продуктов компании ЗоЯмаге 
Савепа, т.е. проводить автоматизированное динамическое тестирование. 

• Помогать группе разработки фиксировать и повторно использовать автоматизирован- 
ные тестовые сценарии для модульного тестирования, тестовые заглушки, драйверы 
и другие объекты тестирования группы разработки. 

• Принимать участие в заседаниях группы управления изменениями с целью установле- 
ния последствий известных ошибок для качества продуктов и влияния предлагаемых 
изменений на определение продукта в процессе тестирования. 

• Помогать группе сборки версий в создании и поддержке автоматизированного комплек- 
та тестов для приемочного тестирования версий в ночное время. 

• Обеспечивать надлежащее управление конфигурацией и контроль версий для всех раз- 
работанных объектов тестирования и используемых вариантов тестовой среды. 


В. Отслеживание результатов и отчетность 


• В соответствии с согласованным процессом проводить исследование и документиро- 
вать отчет о дефектах немедленно после обнаружения проблемы качества. 

• В соответствии с согласованным процессом обновлять информацию о ходе выполнения 
тестов в рамках регулярной отчетности о ходе тестирования в проекте. 

• Отслеживать тестовые сценарии и результаты их выполнения относительно конкретных 
рисков качества. 


• Помогать тест-менеджеру в подготовке отчетов о ходе работ по тестированию и измере- 
нию тестирования (например, с помощью инструментальной панели тестирования). 


С. Управление и надзор 


е Предоставлять тест-менеджеру тщательно проведенные точные оценки продолжитель- 
ности выполнения порученных задач, а также данные о степени надежности оценок 
и предсказуемых зависимостей. 


• Помогать тест. -менеджеру в подготовке планов тестирования, бюджетов и графиков. 


• Участвовать в интервью кандидатов на должности инженеров по ручному и автоматизи- 
рованному тестированию и младших тестировщиков, включая подготовку и проверку 
контрольных заданий. 


• Оказывать техническую поддержку младшим тестировщикам и начинающим инжене- 
рам-тестировщикам согласно данным поручениям. 


Рис. 9.3. Подробное описание должностных обязанностей для письма 
с предложением о занятии вакансии и для проверки качества работы 
сотрудника 
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Предоставлять информацию тест-менеджеру о производительности и качестве работы 
младшего персонала согласно данным поручениям. 


Квалификация, образование и карьерный рост 


При отсутствии степени бакалавра поступить на утвержденные курсы для получения 
степени бакалавра согласно описанию в “Программе содействия развитию карьеры 
персонала". 


При наличии степени бакалавра начать подготовку по утвержденной программе продол- 
жения образования согласно описанию в “Программе содействия развитию карьеры 
персонала”. 


Совместно с тест-менеджером участвовать в ежеквартальной оценке состояния ключе- 
вых навыков группы тестирования, ставить и достигать цели повышения квалификации 
в трех (как минимум) согласованных разделах знаний посредством внутреннего взаим- 
ного обучения и внешних (семинарь/курсы/конференции) возможностей обучения. 


Подписаться на один или более научных или отраслевых журналов по тестированию или 
контролю качества программного обеспечения, согласно описанию в “Программе со- 
действия развитию карьеры персонала”, и регулярно читать их. 


Приобретать ежеквартально не менее одной книги по тестированию или контролю каче- 
ства программного обеспечения, читать их и готовить презентации для учебных семина- 
ров группы тестирования согласно описанию в “Программе содействия развитию карье- 
ры персонала”. 


Отношение к делу и самостоятельность 


Устанавливать и поддерживать хорошие рабочие отношения, особенно в рамках группы 
тестирования и с теми сотрудниками, которые регулярно взаимодействуют с ней. 


По согласованию с тест-менеджером направлять усилия на выполнение приоритетных 
задач тестирования и проекта в целом. 


Находить правильное соотношение между собственными инициативами, касающимися 
тестов, результатов тестирования и дефектов, и ограничениями бюджета и сроков проекта. 


Демонстрировать профессиональный пессимизм, т.е. работать с установкой на поиск, 
документирование и отстаивание необходимости исправления дефектов, не допуская 
конфликтов. 


Проявлять инициативу при определении и достижении целей в обстановке управляемых 
изменений. 


Понимать роль тестирования в жизненном цикле разработки программных продуктов 
и в рамках ограничений проекта, связанных с вопросами бизнеса, уметь защищать наи- 
лучшее из возможных мнений пользователя о системе при заданных параметрах. 


Исполнитель: 


Я ознакомился и полностью понимаю должно- 
стные обязанности, описанные выше. Я также 
понимаю, что невозможность соответствовать 
ожиданиям, определенным выше, может стать 
причиной привлечения к дисциплинарной от- 
ветственности и/или увольнения. 


{ФИО печатными буквами} 


Должность: Инженер по автоматизированному 
тестированию 


Наниматель: 

Сотрудник, согласный с этой вакансией, дол- 
жен подвергаться проверке и оценке на осно- 
ве данной должностной инструкции, а также 
общеупотребительных стандартов, связанных 
с профессией. Никаких изменений этой долж- 
ностной инструкции не допускается без согла- 
сия Исполнителя. 


{ФИО печатными буквами} 
Должность: Тест-менеджер 


Рис. 9.3 (продолжение) 
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Предоставление сотруднику долгосрочного пути развития 
карьеры | 


Тестирование имеет плохую репутацию. Многим удалось построить успепе 
ную карьеру в этой области, но многие рассматривают тестирование как 
смертельный тупик для карьеры и пытаются выбраться из него как можно 
быстрее. Это представление является реальностью только в практике не- 
которых менеджеров ставить черную метку на тестировщиков. Однако 
непосредственные исполнители, которые видят тестировщиков, привя- 
занных к своим обязанностям вопреки их желанию, обычно сами не распо- 
ложены к обязанностям тестировщиков, даже на временной основе. 

Например, однажды я как тест-менеджер беседовал с кандидатом на за- 
нятие вакантной должности, который не знал, на какую вакансию он про- 
ходит интервью. Он уже однажды работал тест-менеджером и описывал 
эту работу как свой горький опыт. Он сказал, что не займет вакансию в 
группе тестирования ни при каких обстоятельствах. Вероятно, никто не 
спросил его, чем он хочет заниматься. Просто кто-то увидел в его резюме 
запись про тестирование, и его привязали к этой категории кандидатов. 
По-моему, это очень грустно и никому не нужно. 

Если посмотреть на мой опыт и на опыт слушателей моих семинаров, 
большинство вариантов развития карьеры для тестировщиков можно 
разбить на две категории: начальный этап карьеры и выбор карьеры тес- 
тировщика. В первой категории тестирование — это старт, или времен- 
ная обязанность, или то и другое вместе. В случае старта люди начинают 
с тестирования, изучая продукт и компанию. В случае временных обязан- 
ностей люди проводят некоторое время в отделе тестирования, работая 
над данным проектом, а затем возвращаются к своей обычной деятельно- 
сти, как правило, больше не занимаясь тестированием. 

Есть две проблемы, касающиеся этих подходов. Во-первых, они недо- 
оценивают уровень квалификации, необходимый хорошему тестировщи- 
ку, особенно навыки тестирования. Для занятия таких вакансий не требу- 
ется никаких навыков тестирования, поскольку вакансия навязывается, 
ане выбирается. Кроме того, из-за временной природы назначения отсут- 
ствуют стимулы улучшения необходимых навыков, за исключением стра- 
ха лишиться возможности перейти на позиции, не связанные с тестиро- 
ванием, из-за низкой оценки качества работы. 

Во-вторых, непрекращающаяся текучка кадров в группе тестирования 
существенно осложняет работу тест-менеджера. Если сотрудник получает 
нежелательное назначение или хочет завершить работу в этой должно- 
сти, чтобы заняться действительно любимым делом, какое можно ожи- 
дать от него качество работы? Если люди непрерывно добавляются в 
группу, как повлияют на эффективность отсутствие экспертизы и необхо- 
димость постоянного обучения основам тестирования? Можно ли соз- 
дать команду единомышленников и управлять уровнем навыков группы, 
если все сотрудники являются временными? 

Выбор карьеры тестировщика делает тестирование отдельным техни- 
ческим направлением развития карьеры в компании. Это направление 
должно находиться на одном уровне с программированием, поддержкой 
пользователей и всеми другими лестницами технической карьеры. Оно 
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должно также предоставлять возможность смены технического направ- 
ления или перехода на менеджерское направление развития карьеры пу- 
тями, аналогичными для других технических направлений. Люди долж- 
ны присоединяться к группе тестирования, поскольку они хотят работать 
вней, хотят оставаться в ней до тех пор, пока не достигнут объявленных и 
запланированных тест-менеджером целей карьеры и не займутся другой 
работой в компании, сохранив теплые воспоминания о времени, когда 
они занимались тестированием. 

Подход, связанный с ротацией (см. главу 8), на самом деле является ва- 
риацией подхода к выбору карьеры тестировщика. (В небольших компа- 
ниях ротация может происходить довольно просто, поскольку в ней 
меньше организационных барьеров для введения ротации.) В этом случае 
каждый исполнитель в группе тестирования выбирает более широкий 
технический путь развития карьеры, приобретает знания, навыки иопыт 
во всех технических направлениях, связанных с разработкой и сопровож- 
дением. Тестирование, программирование, поддержка пользователя и 
другие технические роли рассматриваются в качестве равных и допол- 
няющих друг друга. Люди меняются ролями, работая в одном проекте тес- 
тировщиками, в другом — программистами, в третьем — сотрудниками 
группы технической поддержки и т.д. Как уже отмечалось в предыдущей 
главе, менеджеры разных направлений должны совместно работать для 
того, чтобы каждый сотрудник получал все необходимые навыки в тести- 
ровании, технологиях и проблемной области для эффективной работы 
на всех этапах ротации. 

Для меня предпочтительны подходы, связанные с выбором карьеры 
тестировщика и ротации. В то же время любой четко определенный 
путь развития карьеры лучше, чем ничего. Если отсутствует определе- 
ние карьерного пути, по умолчанию группа тестирования становится 
тихой заводью и превращается в болото для некомпетентных и нело- 
яльных сотрудников компании. В те времена, когда я наблюдал такие 
ситуации, властвовал закон джунглей. Те, кто чувствовал, что их при- 
гвоздили к ролям тестировщиков, всеми возможными способами пыта- 
лись отбиться от этих ролей. Такие действия наносили серьезный 
ущерб группе тестирования и ставили в тупик тест-менеджера. Если вы 
попали в такую ситуацию, мой совет: немедленно увольняйте нелояль- 
ных и некомпетентных сотрудников, приносящих наибольший вред 
группе. Затем включите в действие весь доступный вам политический 
капитал и всю энергию, чтобы совместно с руководством выработать 
какую-либо стратегию развития карьеры, которая является справедли- 
вой и приемлемой для всех участников. 


Выплата сотрудникам справедливой заработной платы, 
соответствующей их квалификации 


Избитое выражение старого менеджмента: “Деньги не являются факто- 
ром мотивации, но они могут выступать в качестве фактора отсутствия 
мотивации”. Другими словами, нельзя побудить с помощью дополнитель- 
ной оплаты кого-либо заниматься работой, которую тот ненавидит, в то 
же время можно вызвать отвращение к любимой работе, если ее оплата 
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не является достаточной. Другое важное соображение связано с тем, что 
зарплатная шкала должна быть справедливой и разумной внутри компа- 
нии, а также должна отражать реалии местного рынка труда. Не уверен, 
что это справедливо для всех, но, что касается меня, удовлетворение от 
работы редко было линейной функцией от суммы денег, получаемой 
мной. 

Деньги имеют значение в двух случаях. Во-первых, зарплата должна 
быть адекватной умениям, навыкам, образованию, а также вкладу, кото- 
рый сотрудник вносит в компанию. Действия компании говорят о том, 
что она ценит тестирование как часть направления деятельности компа- 
нии, тестировщиков как личностей, вклад группы тестирования в общее 
дело, если она устанавливает зарплатную шкалу для тестировщиков, со- 
поставимую с зарплатными шкалами для других направлений развития 
технической карьеры. 

Во-вторых, деньги имеют значение, поскольку зарплатные шкалы 
сами способствуют тому или иному выбору пути развития карьеры. Если 
зарплаты сопоставимы и существует возможность выбора карьерного 
пути, позволяющего переходить с направления тестирования на другие 
позиции и наоборот, единственным фактором, который должен рас- 
сматривать кандидат, является то, насколько он получает удовлетворе- 
ние от работы тестировщика и насколько хорошо он с ней справляется. 
В то же время, если позиции тестировщиков оцениваются более скром- 
ной зарплатой или не дают возможностей для развития карьеры, только 
те люди, которые не умеют делать ничего другого, будут работать на 
этих позициях. Это ведет к оправданию низких заработков для тести- 
ровщиков сеще большим оправданием тупиковой ветки развития карье- 
ры для тестирования. 

Вероятно, вы сталкивались с проблемами, продвигая идею параллель- 
ной зарплатной шкалы для тестировщиков у вашего руководства. Это осо- 
бенно верно, если в сочетании с отсутствием путей развития карьеры, 
тестирование становится парией компании. Довольно трудно аргументи- 
ровать, что тестировщики заслуживают повышения зарплаты, если поло- 
вина группы тестирования состоит из людей, которые, едва избежав 
увольнения, были направлены в тихую заводь тестирования. Однако, 
если вы соглашаетесь с этим статусом-кво, чтобы избежать конфликтов, 
вы позднее окажетесь перед лицом более серьезного конфликта и допол- 
нительных трудностей. Если тестирование является нежелательным бо- 
лотом в вашей компании, берите ситуацию в свои руки и занимайтесь ее 
разрешением. Начинайте бороться с самого первого дня пребывания 
в компании, даже до занятия должности, если это возможно, и не позво- 
ляйте проблеме загнивать. 

Обзоры зарплат и отраслевые журналы рассказывают разные истории 
о конфликтах, связанных с паритетом зарплат тестировщиков и разра- 
ботчиков. Конечно, многие обзоры зарплат тенденциозны, и содержа- 
ние любой статьи, которую вы читаете, зависит от экономической ситуа- 
ции, местного рынка труда, точки зрения журналиста и т.п. В некоторых 
случаях новые сотрудники и кандидаты сообщают о зарплатах тестиров- 
щиков на 10 — 15% ниже, чему разработчиков. Однако другие обзоры зар- 
плат показывают, что тестировщики больше не страдают от диспаритета 
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зарплат с другим техническим персоналом, когда такие факторы, как 
опыт работы и образование, одинаковы . Можно воспользоваться этими 
зарплатными обзорами при разработке для компании презентации о том, 
что уравненная в правах профессиональная группа тестирования являет- 
ся шагом в будущее и что компания должна двигаться по направлению 


к такому будущему. 


Поддержка сотрудников с достаточным образованием, опытом, 
умениями и навыками 


В предыдущей главе рассказывалось о некоторых инструментах, по- 
зволяющих удостовериться в том, что мы берем на работу тех людей, ко- 
торые нам действительно подходят. Эти инструменты доступны менед- 
жеру, отвечающему за прием новых сотрудников. В моем арсенале 
ключевыми инструментами являются перечень должностных обязанно- 
стей и таблица ключевых навыков. Я применяю их с целью привлечения 
и найма сотрудников и для создания группы тестирования вокруг подхо- 
дящих людей. Хотя пригодность людей характеризуется, естественно, не- 
сколькими параметрами, которые трудно измерить, нередко измеряемые 
параметры, например образование, опыт и навыки, помогают мне найти 
хороших кандидатов. В предыдущей главе рассматривались некоторые 
варианты прохождения обучения, доступные профессиональному тести- 
ровщику. Я не готов рекомендовать один набор образовательных крите- 
риев для всех тестировщиков, но предлагаю вам подумать о том, какой 
уровень образования подходит вашей группе тестирования с учетом об- 
щего контекста компании, долгосрочных целей развития карьеры в Ком- 
пании каждого тестировщика и конкретных потребностей группы тести- 
рования в знаниях, умениях и навыках. 

Я предпочитаю работать не только с квалифицированными, но и с опыт- 
ными тестировщиками. Обычно мне хочется, чтобы инженеры-тестиров- 
щики имели опыт работы не менее пяти лет. Я нанимаю младших тестиров- 
щиков без опыта работы, поскольку столь недорогие ресурсы тестирования 
позволяют группе тестирования выполнять большие объемы регрессионно- 
го тестирования, которые в противном случае мы не смогли бы себе позво- 
лить. В то же время неопытным инженерам требуется больше времени для 
продвижения по карьерной лестнице. Опыт особенно важен для тестиров- 
щиков, поскольку большую часть времени занимает доведение до сведения 
людей информации, которую они не хотели бы знать, и работа в калейдоско- 
пически меняющихся условиях. Люди изучают программирование в коллед- 
же, когда получают степень в области компьютерных наук, но их вряд ли 
учат тому, как справиться с недовольными коллегами из других групп и ме- 
неджерами. 

Наконец, что касается навыков, я считаю, что полезным руководством 
при найме сотрудников является таблица ключевых навыков. Однако ее 
нужно использовать с осторожностью. Жесткое применение этого подхо- 
да может закрыть двери перед некоторыми людьми, которые могут ока- 


1 Ежегодные обзоры зарплат можно найти в “Сопітасі Руо/є55іопа" и "Онаїйу Ртојеѕѕіопа!. 


Также можно воспользоваться ресурсами, аналогичными ммм.ѕајагу.сот. 
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заться отличными тестировщиками. Например, зачем утверждать, что ка- 
ждый тестировщик должен уметь программировать, если большая часть 
вашей грунпы занимается тестированием поведения продуктов? Часто я 
вижу, как сообразительные люди быстро овладевают нужными навыками. 
Можно уточнитьпроцесс поиска сотрудников, добавив практикуускорен- 
ного обучения в группе тестирования. В то же время кому-то из выбран- 
ных вами, но имеющих большие пробелы в знаниях по многим ключевым 
направлениям, нужно больше времени, чтобы стать полноценным со- 
трудником группы тестирования, и в течение всего этого времени потре- 
буется обучение или другая поддержка со стороны остальных сотрудни- 
ков группы. 


Подходящая специализация 


В некоторых случаях может оказаться, что пробелы в навыках большой 
группы тестирования являются результатом специализации. В нашем 
примере группа тестирования -- это небольшая команда специалистов по 
общим вопросам тестирования лишь с одним различием: одни ориенти- 
рованы на решение задач, связанных с автоматизированным тестирова- 
нием, а другие на решение задач, связанных с ручным тестированием. 
Также отметим достаточно серьезные ожидания Джамала от инженеров- 
тестировщиков в связи с предъявляемыми требованиями относительно 
умений и навыков. 

В небольших группах специализация опасна, поскольку каждый участ- 
ник становится в определенном смысле незаменимым, по крайней мере, 
в короткий срок. С точки зрения оценки навыков, ключевыми являются 
минимальные значения уровня развития навыков, поскольку каждый из 
специалистов должен быть компетентным в различных областях знаний. 
Предположение, что в ходе проекта никто не заболеет, не забеременеет 
или не будет переживать несчастье, например, связанное со смертью род- 
ственников, является весьма рискованным. Но мы как раз неявно делаем 
такое предположение в случае специализации в небольших группах тес- 
тирования. 

Для больших групп тестирования, вероятно, имеет смысл более разви- 
тая специализация. В одном из проектов, где я был тест-менеджером, тес- 
тировалось Интернет-приложение. Мы разбили тестирование на две час- 
ти: серверную и клиентскую сторону. Тестировщики серверной стороны 
сконцентрировали усилия на проверке большого серверного кластера, 
который работал с электронной почтой, выполнял обновления программ 
и другие сервисы. Тестировщики клиентской стороны занимались уст- 
ройствами доступа в Интернет. 

Я взял двух инженеров-тестировщиков, одного для серверной сторо- 
ны, второго для клиентской стороны. Тестировщик серверной стороны 
имел опыт работы с ОМІХ и автоматизации тестирования, тестировщик 
клиентской стороны обладал хорошим опытом работы с почтовыми сис- 
темами, браузерами и Интернет-технологиями. Также я нашел инженера 
по тестированию удобства использования. Поскольку нужно было моде- 
лировать 50 000 пользователей, я принял на работу двух программистов- 
тестировщиков. Они покончили с многократным использованием боль- 
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шого количества заглушек и драйверов для модульного тестирования, 
разработав генераторы загрузки, которые дали возможность тестировать 
серверы и отклики клиентских машин, если те были соединены с загру- 
жаемыми серверами, на желаемом уровне загрузки. Поскольку мы исполь- 
зовали большое количество тестовых сценариев ручного тестирования, 
инженеры-тестировщики подготовили скрипты, выполнять которые 
было поручено шести младшим тестировщикам. Эта группа, будучи отра- 
жением проекта, работала очень слаженно. 

Некоторые группы тестирования вынуждены обслуживать сразу не- 
сколько проектов. Например, один из моих клиентов располагал един- 
ственным, очень большим отделом тестирования, который назывался 
Центр тестирования отличного качества (Теѕііпе Сепіег ої ЕхсеПепсе). 
Они считали, что тестирование есть специализация внутри себя. В та- 
ких больших сервисных отделах группа управления тестированием мо- 
жет выбрать различные пути организации. Один путь — на основе проек- 
тов, когда тестировщики назначаются в единственный проект на все 
время его выполнения. Второй путь — на основе квалификации, когда 
тестировщики вводятся в проект и выводятся из него по мере необходи- 
мости навыков, присущих именно им. В этом случае вероятно, что в про- 
екте работает на постоянной основе только тест-менеджер или ведущий 
тестировщик . Еще один вариант организации -— на основе предостав- 
ляемых сервисов, вокруг конкретных услуг, которые предоставляет ком- 
пания”. 

Кандидат, который прекрасно подходит для организации группы тес- 
тирования на основе квалификации, может не подходить для организа» 
ции на основе проектов. Некоторые тестировщики действительно хотят 
развиваться в определенных областях технологий. Только организация 
группы тестирования на основе квалификации позволяет такую специа- 
лизацию. Аналогично, кандидат, подходящий для проектной организа» 
ции группы тестирования, может не подойти для организации на основе 
квалификации. Например, однажды я работал с инженером-тестиров- 
щиком, который абсолютно не справлялся с работой в случае, если отве- 
чал за выполнение нескольких задач одновременно. Он рассматривал на- 
значение в несколько проектов одновременно как неподъемную для него 
обязанность. 

Отличная группа тестирования станет за одну ночь слабой, если воле- 
вым решением руководства будет осуществлен переход от одной модели к 
другой. Я также наблюдал, как одна заурядная группа тестирования стала 
отличной в результате перехода к модели на основе квалификации и куль- 
тивирования экспертизы и специализации. Я уверен, что обе модели мо- 
гут работать, если руководство понимает суть специализации и ее влия- 
ние на группу, когда принимает решения по поводу процесса создания 


группы. 


15 Подробнее об этих и других вопросах управления группой тестирования рассказывается 
в главе 8 книги “Мапаріпр йе Тезётр Рүосеѕѕ, Зесота Е@йот”. 


Подразделения тестирования, организованные на основе предоставляемых сервисов, 
обсуждаются в статье “Ах Хоиг Ѕегуісе” Роберта Сабурина (Кобен Забоигіпе), впервые опуб- 
ликованной в “боЙшате Тезііпр апі диа Шу Епріпеегіпр", УоГагое 3, [55ще 3 и доступной в настоя- 
щее время на муг.5іскутіпаѕ.сот. 
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Решение проблем 


Даже когда все вопросы, связанные с подбором кадров решены, могут воз- 
никать различные проблемы. 


Что должны уметь тестировщики и что вы можете получить? 


В мире тестирования продолжаются споры о том, какие из навыков явля- 
ются ключевыми для тестировщиков. Я разбил все навыки на четыре ка- 
тегории: общие, технические, знание предметной области и тестирова- 
ние. Я уверен, что относительное значение каждой из категорий зависит 
от того, какая система тестируется, включая ее технический аспект 
и бизнес-аспект. Однако некоторые люди выступают в защиту повышен- 
ной технической экспертизы, на том же уровне, что и у группы разработ- 
ки, в качестве необходимого условия для всех тестировщиков. Другие вы- 
ражают скепсис, если группа тестирования составлена из людей, не 
являющихся специалистами в проблемной области приложения. Как ре- 
шить, какие и какого уровня навыки нужны квалифицированному тести- 
ровщику? 

Есть три аспекта этой проблемы. Во-первых, остается вопрос опреде- 
ления компетентности. Что тестировщик должен знать, чтобы эффек- 
тивно и качественно выполнять свои обязанности? Требования в терми- 
нах технических знаний часто являются функцией того, какие объемы 
задач структурного тестирования (белого ящика), контроля качества 
(просмотр кода) и автоматизации тестирования будет выполнять тести- 
ровщик. Необходимые знания предметной области зависят от сложно- 
сти, неизвестности и рисков, относящихся к проблеме бизнеса, которую 
призвана решать система. Текстовый процессор — это понятное прило- 
жение, а система разведки нефтяных месторождений далеко не очевид- 
на. Лишь виртуальные проблемы могут возникнуть в случае краха видео- 
игры, тогда как от надежности систем управления вооружениями зависят 
человеческие жизни. 

Однако я встречался с ситуациями, когда тестировщик должен был (или 
мог) проводить только тестирование поведения системы (черного ящика) 
в некритичной для безопасности среде. Но когда я предложил воспользо- 
ваться услугами экспертов по тестированию или младших тестировщиков, 
людей с минимальными знаниями проблемной области и техническими 
навыками, реакция была отрицательной. Один из моих предполагаемых 
клиентов не хотел использовать непрограммистов в качестве тестировщи- 
ков для его видеоигры, поскольку он предполагал, что группа тестирова- 
ния будет проводить и структурное и поведенческое тестирование. Когда 
я предложил использовать менее дорогих младших тестировщиков для по- 
веденческого тестирования и нанять одного или двух высокооплачивае- 
мых человек с техническими навыками и навыками тестирования, он отка- 
зался. Один из клиентов, менеджер центра обработки звонков по ссудам, 
скептически отзывался о тестировании приложения обработки ссуд, по- 
скольку его проводили профессиональные тестировщики, а не банкиры 
центра. Этот скептицизм не исчез даже после того, как мы обнаружили 
серьезные ошибки в продукте. 
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Эти примеры иллюстрируют вторую сторону рассматриваемой про- 
блемы. Поскольку тестирование - это создание новой информации, дове- 
рие кгруппе тестирования является ключевым фактором успеха. Незави- 
симо от того, насколько компетентны тестировщики, работающие с 
продуктом, если есть мнение ключевых участников разработки, что они 
некомпетентны, группе тестирования не будут доверять. В таком случае 
группа тестирования имеет большие шансы на неудачу в проекте и рос- 
пуск, даже если работа проведена отлично. 

Таким образом, поскольку мы считаем, что тестировщики не только 
должны быть компетентными, но и слыть компетентными среди ключе- 
вых участников разработки, мы рассматриваем третью сторону проблемы. 
На самом деле непросто найти тестировщиков, которые хорошо знают 
проблемную область, имеют опыт работы с применяемыми технологиями, 
а также обладают отменными навыками тестирования и правильным отно- 
шением к делу. Можно повысить вероятность решения проблемы, если 
есть возможность нанять консультантов или контрактников, поскольку 
многие из тех, кто обладает всеми тремя наборами качеств, не доступны на 
свободном рынке труда и требуют огромной зарплаты в соответствии со 
своей квалификацией. 

В то же время трудно убедить руководство финансировать группу тес- 
тирования, состоящую из дорогих консультантов. Кроме того, поскольку 
есть намерение создать постоянную группу, консультанты и контрактни- 
ки смогут оказать помощь вее совершенствовании, но не нужно создавать 
долговременной зависимости от этих ресурсов, если вы не рассчитывае- 
те убедить их стать постоянными сотрудниками. Таким образом, перед 
вами встает проблема создания компетентной группы, которая по средст- 
вам компании и которой доверяют. 

Момент, когда вы должны добиваться баланса, зависит от ситуации. 
Нужно работать над этим вместе с руководством и другими ключевыми 
участниками проекта по мере того, как вы формулируете перечень долж- 
ностных обязанностей, находитесь в непосредственном контакте с клю- 
чевыми участниками и вашими руководителями. Разберитесь с проблема- 
ми доверия и доступности средств, связанными с тем, насколько высоко 
будет поставлена планка. Убедитесь, что все принимают компромиссные 
решения, которые вам приходится предлагать. Не начинайте проект 
даже с безупречно компетентной группой тестирования, если неизвест- 
ны (иногда нереалистичные) ожидания других участников проекта отно- 
сительно навыков группы или возврата вложений в тестирование. 


Белые слоники 


Когда я был маленьким, мама и бабушка иногда брали меня в походы по 
антикварным магазинам. Антикварные вещи были тогда менее модными, 
чем сейчас, и их часто называли “подержанными вещицами”, “вещами, 
передаваемыми по наследству” и даже “белыми слониками”. Последняя 
фраза всегда смущала меня (мама объяснила, что она происходит от боль- 
шого числа глиняных статуэток, которые можно было найти в любом ан- 
тикварном магазине), но она сохранилась в памяти до сих пор. 
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Иногда кажется, что тест-менеджеры заполняют группу тестирования 
в магазинах, продающих белых слоников. Одна из групп тестирования, 
которыми я руководил, состояла исключительно из людей, которым не 
удалось стать программистами. Один из них оказался отличным инжене- 
ром-тестировщиком, а двое других не продемонстрировали больше спо- 
собностей к тестированию, чем к программированию. Мне разрешили их 
уволить, но без гарантии, что удастся заполнить вакансии. 

Сейчас я стал старше и умнее и научился сопротивляться набегам 
белых Слоников'. Однажды менеджер разработки, узнав, что один из ин- 
женеров сборки решил уйти, настаивал на том, чтобы я взял его в группу 
тестирования. Я отказался. Другой случай: бизнес-аналитик привел безра- 
ботного родственника на интервью, поскольку он услышал, что группа 
тестирования ищет сотрудников. Из резюме этого человека было ясно, 
что он не обладает квалификацией. Чтобы окончательно убедиться 
в этом, я задал несколько провокационных вопросов на групповом интер- 
вью, на котором присутствовали коллеги бизнес-аналитики. Эти вопросы 
деликатно, но однозначно продемонстрировали отсутствие у кандидата 
навыков и опыта в ключевых разделах, которые мы хотели закрыть 
с приемом нового сотрудника. 

Чтобы вы не сочли меня параноиком, позвольте заметить, что в своем 
мнении по этому поводу я не одинок. Борис Бейзер (Вог15 Веігег) писал: 
“Я получил свою дозу “бедных-несчастных”, некомпетентных, невроти- 
ков, психов, [и] алкоголиков” ? Сем Канер (Сет Капег), Джек Фолк (Јаск 
ЕаК) и Енг Нгуен (Нипо Мкиуеп) согласны, что тест-менеджеры должны 
сопротивляться усилиям наполнить группу тестирования программиста- 
ми-неудачниками`. В группу тестирования должны приниматься сотруд- 
ники, которые хотят в ней работать и навыки, знания и личные качества 
которых подходят для группы. Чем включить в группу тестирования него- 
дяя, лучше пусть у вас будет на одного человека меньше, чем требуется. 

Итак, программист может попасть в неприятности по целому ряду 
причин, не последней среди которых является слабое руководство. Если 
у человека есть подходящие навыки и знания и его считают компетент- 
ным в группе тестирования, я не стал бы рассматривать факт, что он был 
гадким утенком в другой группе, как препятствие, мешающее принять ле- 
бедя в мою команду. 


Использование контрактников и консультантов 


В некоторых случаях верным решением для группы тестирования являет- 
ся не прием нового сотрудника, а приглашение контрактника или кон- 
сультанта. Для временных потребностей, например в ходе пиковых загру- 
зок тестировщиков в проекте, использование контрактников имеет 
большой смысл. Я выполнил приличное число проектов с большой за- 


і Роберт Сабурин (Кобегі Ѕабоџгіпе), один из рецензентов, предоставил мне ссылку на 


меб-сайт, рһгаѕеѕ.5һи.ас.иК /тоеапіпрѕ /410050.ті, так что теперь я знаю точное значение 
и происхождение термина “белые слоники”. 


2 Вонз Вейтег, «5о/їшате Зузієт Тейтя апа Опангу Азѕитатсё“, раве 317. 
3 Сет Капег, Јаск Каїк апа Нипе М№еџуеп, " Тезійпе Сотриіет Зойшат?’, раве 359. 
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грузкой, когда начинал работать с группой контрактников, по ходу проек- 
та проводил тестирование, а затем осуществлял переход к постоянной 
группе, часто помогал при наборе персонала и иногда превращал часть 
контрактников в постоянных сотрудников компании-клиента. Такой под- 
ход отлично работал и для меня, и для моих клиентов. Вероятно, вы захо- 
тите воспользоваться услугами консультанта для проведения обучения 
или нечастых советов по трудным проблемам. 

Перед тем как нанять консультанта или контрактника, необходимо 
определить, для чего вы нанимаете этого человека. Я часто получаю теле- 
фонные звонки и электронные сообщения от людей, которые можно 
сформулировать примерно так: “У меня есть ряд непонятных организаци- 
онных трудностей, связанных с тестированием, и я бы хотел, чтобы вы 
помогли ихустранить”. В некоторых случаях дальнейшие уточняющие во- 
просы показывают, что указанные проблемы не имеют отношения к тес- 
тированию, а являются проблемами управления, которые проявились 
в ходе одной из фаз тестирования. 

Если вы можете четко сформулировать, что должен делать контракт- 
ник или консультант, вам обоим понравятся результаты работы, в про- 
тивном случае — берегитесь. Например, предположим, что вы сообщили 
представителю группы продаж компании по поиску временных сотрудни- 
ков: “Тестирование требует очень много времени, мне нужно автоматизи- 
ровать его часть”. Практически сразу ваш факс переполнится резюме 
всех кандидатов, которые когда-либо видели инструмент автоматизиро- 
ванного тестирования, трогали его или были в той же комнате, где он на- 
ходился. Если вы примете на работу кого-нибудь из этого пула кандидатов 
только на основе продолжительности опыта по автоматизации тестиро- 
вания или потому, что они знают инструмент, который вы планируете 
приобрести, отрицательный результат очень вероятен. 

Напротив, предположим, что вы позвонили своему приятелю агенту 
по подбору кадров, живущему по соседству, и сказали: “Послушай. Мы ре- 
шили, что у нас слишком много проблем с регрессионным тестированием 
в версиях сопровождения. Вместо того чтобы нанимать еще десяток тес- 
тировщиков для проведения ручного тестирования, мы бы хотели вло- 
жить средства в подробный комплект автоматизированных тестов. По- 
этому мне нужен кто-то, чтобы помочь выбрать инструмент. Этот человек 
должен иметь опыт работы с разнообразными инструментами и не боять- 
ся осваивать новые. Как только инструмент будет выбран и развернут, 
нам потребуется специалист, который поможет разработать этот ком- 
плект тестов, а затем обучит одного из старших тестировщиков, как при- 
менять тесты и сам инструмент. После этого контрактник должен сразу 
завершить свою работу в компании или постепенно свернуть свое уча- 
стие в течение нескольких недель. Одним из показателей успешности его 
работы является то, насколько он может сделать процесс работы с теста- 
ми и инструментами независимым от его участия. Мы планируем, что он 
будет работать примерно шесть месяцев, но мы открыты для переговоров 
с кандидатом по этому вопросу. Наконец, каждый кандидат, которого вы 
направляете на интервью, должен предоставить три рекомендации от 
компаний, в которых он выполнял проекты, аналогичные нашему. По- 
нятны ли наши требования, есть ли у тебя вопросы?” 
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Оценивая квалификацию консультантов и контрактников, вы должны 
ответить на целый ряд вопросов. Вы часто ищете специалистов с квали- 
фикацией, превосходящей вашу собственную. Как можно узнать, что вы 
говорите с экспертом, а не с умеющим себя подать неквалифицирован- 
ным человеком? Как вы поймете, что контрактник или консультант, кото- 
рый получил сертификат в некотором разделе технологий, предметной 
области или тестировании, может применить и реально применял свои 
знания в реальном проекте? Как вы узнаете, что контрактник, который 
рекламировался агентом по персоналу в качестве идеального кандидата, 
не превратится в вашу головную боль через несколько дней после того, 
как агент получит комиссионные. Понимаете ли вы проблему, которую 
должен решить контрактник, достаточно хорошо для того, чтобы пред- 
ставить, кто должен ее решать, и понять, решал ли он ее когда-то в про- 
шлом? 

Квалифицированные консультанты и контрактники имеют большой 
перечень отменных рекомендаций, которые сообщают о хорошо выпол- 
ненной ими работе. Приглашения специалистов обычно имеют свою спе- 
цифику, однако я обращаю внимание на навыки, отношение к делу и обра- 
зование, которые я определил как существенные для моей группы 
тестирования. Как контрактник применил навыки автоматизации тести- 
рования для решения реальных проблем разработки или сопровожде- 
ния? С какими видами проблем он уже сталкивался в предыдущей работе? 
Способствовало ли образование кандидата качественному выполнению 
работы? 

Помимо рекомендаций, вероятно, кандидат оставил за собой право 
использовать один или несколько результатов, достигнутых у предыду- 
щих клиентов, в качестве примера его работы. Предусмотрительные кан- 
дидаты и контрактники обычно включают в свои контракты условия, ко- 
торые позволяют ему после удаления идентификационной информации 
использовать примеры своей работы. 

Квалификация также может быть продемонстрирована с помощью 
списка публикаций или лекций по тестированию, прочитанных по при- 
глашениям. Известные эксперты рецензируют большинство научных 
и отраслевых журналов и книг, посвященных тестированию. Хотя публи- 
куются сомнительные и иногда спорные статьи, подавляющее большин- 
ство людей, незнакомых с тестированием, непонимающих его процессов 
и проблем, сочтут невозможным публиковаться. Электронные форумы, 
в частности Интернет-телеконференции и обсуждения, также могут пока: 
зать знание тестирования, хотя отсутствие экспертных оценок иногда 
приводит ктому, что гуру и болтун отнимают одинаковую долю внимания 
аудитории. 

° Если разрешено местными законами, еще один способ гарантировать 
качественный подбор консультанта или контрактника для решения ва- 
ших проблем — испытательный срок и внесение в контракт условий его 
прерывания. Я не стану рекомендовать ничего непорядочного, хотя не- 
которые действительно пытаются необоснованно прервать контракт 
с консалтинговыми фирмами. Напротив, я говорю о том, чтобы опреде- 
лить измеряемые контрольные точки для оценки работы консультанта 
или контрактника. Эти контрольные точки должны помочь провести 
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оценку хода выполнения работ и их качества. Если работы не выполнены, 
контракт должен давать возможность справедливо, по взаимному согла- 
сию, но достаточно быстро для вас как заказчика прекратить действие 
контракта и уволить консультанта. 

Политика моей собственной фирмы как консалтингового учреждения 
состоит в том, что мы хотим получать деньги только с клиентов, доволь- 
ных нашей работой, поскольку мы получаем рекомендации и отзывы о на- 
шей работе. Поэтому мы включаем в наши контракты условия прерыва- 
ния. Другое преимущество таких условий проявляется следующим 
образом. Дополнительно гарантируя, что конкретная работа будет вы- 
полнения в соответствии с графиком, условия прерывания контракта 
предотвращают бурную реакцию заказчика в случае небольших инциден- 
тов, а это не оказывает влияния на главную причину, по которой заказчик 
нанимает контрактника. Если прерывание контракта инициируется при 
особых условиях, четко прописанных в контракте, это способствует 
тому, что заказчик концентрируется натой работе, для выполнения кото- 
рой приглашен контрактник или консультант. 

Наконец, позвольте отметить, что сложный и иногда болезненный 
процесс приглащения консультантов и контрактников может быть суще- 
ственно упрощен за счет создания и последующего использования 
обширных связей в сообществе тестировщиков программного обеспече- 
ния. Если вы читаете сообщение в телеконференции или статью в журна- 
ле о тестировании, которая задевает вас, то, вероятно, обнаружите, что 
ее автором является консультант, специализирующийся как раз на той об- 
ласти знаний, в помощи в которой вы нуждаетесь. Поговорите с коллега- 
ми, которых вы встречали научебных семинарах и конференциях, чтобы 
узнать, чьими услугами они пользовались. Узнайте про профессиональ- 
ную репутацию как самих консультантов, так и компаний, в которых они 
работают. 


Внедрение усовершенствований 


Как уже упоминалось в начале предыдущей главы, процесс создания груп- 
пы тестирования очень зависим от конкретной ситуации и подвержен 
разнообразным влияниям. Следовательно, особенности совершенствова- 
ния этого процесса будут зависеть от того, что вы делаете сейчас и что 
возможно сделать в рамках вашей компании. Тем не менее позвольте вы- 
сказать несколько идей, которые, как я заметил, получили широкое при- 
менение. 


1. Обеспечьте совместимость контекста тестирования и группы тес- 
тирования. Еще один результат процесса определения контекста 
тестирования, представленного в главе 1, состоит в том, что он по- 
зволяет понять, ту ли команду вы формируете. Как наилучшим об- 
разом вы можете обеспечить потребности компании? 


2. Внедрите проведение оценки навыков и управление ими. Если вам 
известно, как обеспечить потребности компании, можно присту- 
пить к определению перечня ключевых навыков, необходимых для 
выполнения этих задач. Можно составить таблицу оценки навыков. 
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Если в группе тестирования уже есть сотрудники, привлеките их к 
процессу создания списка ключевых навыков. 


3. Подготовьте и предложите пути развития карьеры для тестиров- 
щиков, постоянно работающих в компании. Определите средства 
для карьерного роста в рамках группы тестирования. Совместно с 
менеджером по работе с персоналом или коллегами-менеджерами 
других групп определите пути развития карьеры с начальных пози- 
ций до других позиций в компании. 


4. При проведении интервью с кандидатами применяйте оценку на- 
выков, вопросы о пути развития карьеры, о линии поведения и кон- 
трольную проверку знаний, чтобы подобрать людей с подходящи- 
ми навыками, опытом, отношением к делу и способностями. 


Создание и совершенствование групп тестирования — это тяжелая ра- 
бота, но усилия, потраченные на нее, возвращаются сторицей. Быть ча- 
стью сильной команды, и в роли менеджера и в роли непосредственного 
исполнителя, — одно из тех ощущений профессионала, которые прино- 
сят наибольшее удовлетворение от работы. Последние две главы были 
посвящены видению этого процесса со стороны менеджера, поскольку 
львиная доля ответственности падает на него. Однако непосредственные 
исполнители могут и должны принимать в нем участие, особенно в совер- 
шенствовании старых и приобретении новых навыков и в уточнении их 
отношения к делу и ожиданий. 

Имея хорошо организованную и подготовленную группу тестирова- 
ния, мы можем перейти к следующей стадии: к созданию системы тестов. 
Имея в наличии хорошую группу тестирования и хорошую систему тес- 
тов, мы сможем приступить к выполнению ‘гестов. 


ГЛАВА 10 


Архимедова ванна: 
проектирование и разработка 
системы тестов 


Л егенда гласит, что греческий царь Гиерон приказал изобретателю 
и математику Архимеду придумать метод определения качества им- 
ператорской короны. Для императора качество означало наличие в коро- 
не единственного элемента — чистого золота, и отсутствие многих неже- 
лательных элементов — примесей других металлов. Архимед не знал, что 
делать, пока однажды он, сидя в ванной, не заметил, как вода переливает- 
ся через край. Открывая закон погружения тел, названный впоследствии 
его именем и позволивший определить качество короны, он воскликнул: 
“Эврика!” Мы, тестировщики, возможно, тоже должны забраться в архи- 
медову ванну, поскольку наша задача — проектирование и разработка эф- 
фективной и качественной системы тестов, которая позволяет оценить 
качество системы, которую мы тестируем. 

Оценка качества имеет две основные цели, связанные с проектирова- 
нием и разработкой системы тестов. Во-первых, мы должны нацеливать 
систему тестов на проверку тех рисков качества системы, которые счита- 
ются наиболее критичными на основе их относительной значимости (см. 
главу 2). Во-вторых, если мы хотим оценить качество, мы должны органи- 
зовать тестирование так, чтобы тестировщики могли четко понимать, ка- 
ким должно быть мнение пользователей и заказчиков о системе. Следова- 
тельно, мы должны предоставить тестировщикам высококачественную 
систему тестов, которая верно воспроизводит мнение заказчиков и поль- 
зователей о системе. 

Моя модель системы тестов состоит из трех основных элементов, как 
показано на рис. 10.1. Глядя на рисунок, можно сделать вывод о формаль- 
ных требованиях к системе тестов, однако это не совсем так. Проектиро- 
вание.и разработка системы тестов иногда начинаются за несколько лет 
до того, как система будет предоставлена группе тестирования, а иногда 
эти два процесса стартуют в один и тот же день. Иногда система тестов 
размещается в большой тестовой лаборатории на гигабайтах дискового 
пространства, в толстых папках с тремя кольцами, а иногда она целиком 
существует только в голове тестировщиков. 
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Рис. 101. Элементы системы тестов 


Глава 10. Архимедова ванна 281 


Проектирование тестов происходит там и тогда, где и когда тестиров- 
щики расходуют время на принятие решений о том, как тестировать кон- 
кретные области системы и как искать в ней конкретные проблемы. 
Эффективное и качественное проектирование тестов означает формули- 
рование точных вопросов по поводу того, что может сломаться. 

Разработка тестов происходит там и тогда, где и когда тестировщики 
расходуют время на реализацию принятых при проектировании тестов 
решений. Эффективная и качественная разработка тестов -- это построе- 
ние системы тестов, которая отвечает на точные вопросы о том, что ло- 
мается и что не ломается; в порядке приоритетов рисков качества систе- 
мы и путем, который непосредственно связан с мнением пользователей и 
заказчиков о системе. 

Эти комбинированныеусилия по проектированию и разработке тестов 
могут быть зафиксированы в любой форме, начиная от заметок, эскизов и 
моделей, выполненных на доске, и заканчивая кипами связанных тестовых 
сценариев и скриптов вместе с дисками и лентами, заполненными данны- 
ми. Эффективное и качественное проектирование и разработка системы 
тестов могут потребовать и минуты, и месяцы. Различные подходы кучету 
соображений, касающихся контекста (см. главу 1), определяют степень 
формализации и неизменности, а также структуру системы тестов. 


Процесс проектирования и разработки 
системы тестов 


Конкретные детали процесса проектирования и разработки системы тес- 
тов существенно различаются для разных стратегий тестирования, кон- 
текста группы тестирования и технологий, поддерживающих систему 
тестов и используемых в системе, предназначенной для тестирования. 
Процесс 7 является общим процессом, который каждый может приспосо- 
бить в соответствии с собственными потребностями. 


Эмма создает напряжение в работе 


В ходе фазы планирования Джамал поручил Эмме Мурхаус обновить тес- 
ты для проверки производительности, нагрузки, мощности и объема 
с учетом новых свойств, которые добавляются в Суматру. 11 ноября, на 
один день раньше срока, Эмма занялась этим. 

Наиболее критичные риски качества возникают в поведении систе- 
мы, когда достигаются границы объема данных и загрузки. Это как раз от- 
носится к комплекту тестов для проверки производительности, нагрузки, 
мощности и объема. (На рис. 10.2 показаны связанные с этими проблема- 
ми риски качества.) Система должна поддерживать 255 пользователей, 
подключившихся одновременно, и всего 32 767 учетных записей пользо- 
вателей, позволяя управлять документами размером до 32 мегабайтов. 
Если оперативная память заполнена целиком, файлы должны направ- 
ляться в почти оперативную память, а затем в автономное хранилище. 
Файлы, помещенные в почти оперативную память и в автономное храни- 
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лище, должны возвращаться в оперативную память при обращении кним 
пользователей, замещая более старые файлы и направляя их в более мед- 
ленные хранилища, чтобы освободить необходимое дисковое простран- 
ство. Должна работать миграция файлов из одного хранилища в другое. 
Причем это должно происходить с максимальной прозрачностью для 
пользователей и с быстрой эскалацией блокирующих ситуаций в библио- 
текаре документов (например, вустройстве чтения нет компакт-диска, на 
котором находится файл с данными), с 99%-ным временем работоспособ- 
ности системы и без потери данных. 


Процесс 7. Процесс проектирования и разработки системы тестов 


№ этапа Этап Выполнено? 
1. Создать или обновить комплекты тестов, покрывающих те а 
риски качества системы, для которых рекомендовано тести- 
рование. 
2: Выбрать надлежащий комплект тестов и придумать новое О 


множество интересных тестовых условий в рамках наиболее 
критичного раздела системы, который еще не покрыт теста- 
ми, т.е. условий, которые могли бы спровоцировать опреде- 
ленный набор проблем или смоделировать практическое ис- 
пользование системы. Определить на верхнем уровне детали- 
зации, как проверить корректность результатов при данных 
тестовых условиях. 


3. Выбрать надлежащие методы тестирования для исследования 0 
тестовых условий и верификации ожидаемых результатов 
с учетом доступных времени и бюджета, тестопригодности 
системы, предназначенной для тестирования, тестовой среды 
и квалификации группы тестирования. 


4. Спроектировать, разработать, приобрести, усовершенство- п 
вать, сконфигурировать и документировать средства тестиро- 
вания, тестовую среду и процесс выполнения тестов для вос- 
произведения определенных условий и проверки поведения 
системы с использованием выбранных методов тестирования. 
Усилить точность методов тестирования с помощью эмпири- 
ческих методов сучетом данных заказчика или пользовате- 
лей, отчетов о проблемах в эксплуатации (для ранних и конку- 
рирующих версий, аналогичных продуктов и аналогичных на- 
боров рисков качества системы), прогнозов отделов продаж и 
маркетинга о будущем использовании системы и других дан- 
ных заказчика. 


5. Если какие-либо элементы средств тестирования, тестовой Пп 
среды или процесса выполнения тестов оказались недоступ- 
ными в ходе выполнения этапа 4 из-за ограничений ресурсов, 
сроков и т.п., повторить этап 4 нужное число раз, чтобы при- 
способиться к этим ограничениям. 


6. Проверить систему тестов, используя статические (например, О 
рецензирование) и динамические (например, выполнение 
тестов) методы. 
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Процесс 7 (продолжение) 


№ этапа Этап Выполнено? 


7. Поместить средства тестирования, описание процесса выпол- О 
нения тестов, информацию о конфигурации тестовой среды, 
документацию о тестировании системы тестов (полученную на 
этапе 6), всю прочую документацию и созданные файлы в биб- 
лиотеку проекта или в систему управления конфигурацией. 

Привязать версию системы тестов к версии системы, предна- 
значенной для тестирования. Вести контроль изменений. 


8. Обновить перечень рисков качества на основе новых знаний, О 
полученных при разработке последних наборов тестов. Оце- 
нить покрытие рисков качества новой системой тестов. Вы- 
явить остающиеся непокрытыми риски качества, для которых 
рекомендовано тестирование. 


9. Повторить этапы 2 - 8, пока не будут покрыты все риски каче- О 
ства, для которых рекомендовано тестирование. Убедиться, 
что документация по рискам качества обновлена в проектном 
репозитории. Если ограничения бюджета и сроков вынужда- 
ют прекратить разработку тестов, подготовить отчет о непо- 
крытых рисках качества и направить его руководству. 


10. Если время и ресурсы позволяют, повторить этапы 2 — 8, ис- о 
пользуя структурный анализ (например, сложность Маккейба 
(МебСабе сотріехісу) и покрытие кода), чгобьг определить об- 
ласти системы, требующие дополнительного тестирования. 
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№ этапа Этап Выполнено? 
1. Создать или обновить комплекты тестов, покрывающих те М 
риски качества системы, для которых в рекомендовано тести- 
рование. | 
2. Выбрать надлежащий комплект тестов и придумать новое М 


множество интересных тестовых условий в рамках наиболее 
критичного раздела системы, который еще не покрыт теста- 
ми, т.е. условий, которые могли бы спровоцировать опреде- 
ленный набор проблем или смоделировать практическое ис- 
пользование системы. Определить на верхнем уровне детали- 
зации, как проверить корректность результатов при данных 
тестовых условиях. 


Эмма изучила документы с описанием требований, посмотрела в пото- 
лок, прошлась по офису, пролистала пару книг по тестированию, а также 
материалы конференций в поиске идей. Наконец она пришла к решению 
использовать три метода. 

Во-первых, в качестве основы для тестирования она решила использо- 
вать подход “мыльной оперы” Ханса Бувальды (Напѕ ВимаїЧа), построив 
очень большой, но поддающийся сопровождению сценарий. Предполо- 
жим, рассуждала она, есть большая группа адвокатов, защищающих не- 
сколько больших транснациональных корпораций против определенно- 
го вида истцов. В частности, представим множество адвокатских контор 
с общим числом служащих в 32 767 человека, участвующих в большом су- 
дебном процессе, начатом против их клиентов, которые находятся в раз- 
личных точках земного шара. 7 дней в неделю 24 часа в день 255 адвокатов 
будут подключены к системе, создавая документы, делая на них ссылки и 
архивируя их с помощью блока управления документами. Документы 
варьируются по размеру от 0 до 32 мегабайтов, поэтому сделаем избыточ- 
ное предположение, что средний размер документа равен 16 мегабайтам 
при выборе документов случайного размера, близкого к среднему, и име- 
ется, по крайней мере, по одному документу с размером, соответствую- 
щим одному из предельных значений. Это модель, возможно, далека от 
реальности, однако она соответствует требованиям и заставляет систему 
непрерывно работать на пределе возможностей". 

Во-вторых, в ходе разработки функциональных тестовых сценариев 
Лин Цу обсуждала с Эммой, как движок редактирования взаимодействует 
с системой управления документооборотом, вынуждая ее проходить че: 
рез разные состояния. Например, когда Зрееду\Мтиег начинает работу, 
нет открытых файлов, но затем пользователь может запросить файл из 
системы документооборота, что приведет к тому, что система представит 
перечень известных ей документов. Теперь пользователь может выбрать 
документ или добавить новый документ в систему. Каждое действие пере: 
водит систему в новое состояние. 

Как только пользователь начинает редактировать документ, управляє: 
мый системой управления документооборотом, периодические сохране 


1 См. статью Ханса Бувальды (Напѕ Вимаїда) “Ѕоар Орега Теѕіпр”, представленную на кон: 


ференции ЗАТЕ Еаѕ 2000, опубликованную в "Реосегаїтрз ор йе ЗТАК Казі 2000" и доступную 
в настоящее время на уууги.3ИсКуп1195.сот. 
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Рис. 10.2. Риски, связанные с нагрузкой, мощностью и объемом (из анализа рисков качества проекта “Суматра”) 
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ния могут привести к тому, что доступная оперативная память будет ис- 
черпана, в результате чего произойдет миграция документов, находящих 
в оперативной и почти оперативной памяти, на другой уровень иерархии 
хранилищ. Другие действия приводят к возникновению иных состояний. 
Некоторые из этих состояний означают успешное сохранение или извле- 
чение документа из системы, другие указывают на необходимость ожида- 
ния внешних действий библиотекаря документов, а третьи фиксируют 
ошибку. Лин Цу применяла метод-тестирования на основе управляющей 
логики программы для проведения функционального тестирования, как 
это описано у Бориса Бейзера. Эмма ожидала, что этот метод также ока- 
жется полезным при нагрузочном тестировании. 

Наконец, Эмма осознала, что ей вряд ли удастся задействовать 255 тес- 
тировщиков, тем более 24 часа в сутки и семь дней в неделю. Однако она 
могла воспользоваться инструментом нагрузочного тестирования, чтобы 
написать простые автоматизированные тестовые скрипты, которые мог- 
ли бы зациклить прохождение системы через различные состояния и 
поддерживать ее непрерывную работу. Эти скрипты работали бы при- 
мерно так, как “тупые обезьяны”, описанные Ноэлем Найманом (М ое! 
Мутап). Такие скрипты могут только обнаружить, что система находится 
в непредвиденном состоянии, но не могут проверить, как система попала 
в это состояние. В то же время Эмма собиралась усилить автоматизиро- 
ванное тестирование за счет полного тестирования состояний и различ- 
ных переходов между состояниями с помощью ручного функционального 
тестирования во время выполнения нагрузочных тестов”. 


№ этапа Этап Выполнено? 


3. Выбрать надлежащие методы тестирования для исследования МІ 
тестовых условий и верификации ожидаемых результатов 
сучетом доступных времени и бюджета, тестопригодности 
системы, предназначенной для тестирования, тестовой среды 
и квалификации группы тестирования. 


Выбрав подходящие методы, Эмма начала готовить средства тестиро- 
вания. Для сценария мыльной оперы она создала 32 767 учетных записей 
на меб-сервере, используя несложную программу генерации учетной ин- 
формации в формате АЗСІ и затем утилиту загрузки файлов в базу дан- 
ных для помещения учетных записей в таблицу на сервере баз данных. 
Для создания файлов, предназначенных для редактирования, она вос- 
пользовалась ТСГ-скриптом. Для редактирования этих файлов она запла- 
нировала использовать те же самые скрипты. Скрипты создали файлы 
в соответствии с простым и предсказуемым образцом. 

Ранее Лин Цу составила график состояний, на котором были изобра- 
жены состояния системы и способы перехода от одного состояния к дру- 


См. описание этого и других полезных методов в книгах Бориса Бейзера (Вогіз Веігег) 
"Віасі-Вох Тейт” и Ли Копленда (І ее Сорейапа) “Маяептр 5о/їшате Тезі Дезірті". 


2 См. статью Ноэля Наймана (Мое Мупап) "Озіпр Мопкеу Тез Тоо|5”, впервые опублико- 
ванную в журнале "5о/їшате Тейтр ата ди у ЕпртееппЕ”, Уоїате 2, Іѕѕие 1 (Јап/Еер 2000) и 
доступную в настоящее время на уулу. 5Искуп!п5.сот. 
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гому. Эмма много раз обращалась к этому графику. Для создания “тупых 
обезьян” 

Эмма с помощью инструмента автоматизированного тестирования 
разработала несложные скрипты. Они представляли собой основные по- 
вторяющиеся действия по созданию, загрузке, редактированию, сохране- 
нию и чтению документов в системе управления документооборотом. 
Эти скрипты могли сообщить об ошибочном состоянии, когда они оказы- 
вались в нем, но не могли проинформировать, как их действия повлияли 
на систему, предназначенную для тестирования. Поскольку файлы дан- 
ных Эммы соответствовали определенному образцу, она могла разрабо- 
тать несложный скрипт, проверяющий корректность файлов, а, исполь- 
зуя средства экспорта каталога системы управления документооборотом, 
она могла бы проверить, что утерянных (отсутствующих в перечне) 
и пропущенных (указанных в перечне, но отсутствующих) файлов в сис- 
теме управления документооборотом нет. 


№ этапа Этап Выполнено? 
4. Спроектировать, разработать, приобрести, усовершенство- 


. вать, сконфигурировать и документировать средства тестиро- 
вания, тестовую среду и процесс выполнения тестов для вос- 
произведения определенных условий и проверки поведения 
системы с использованием выбранных методов тестирования. 
Усилить точность методов тестирования с помощью эмпири- 
ческих методов с учетом данных заказчика или пользовате- 
лей, отчетов о проблемах в эксплуатации (для ранних и конку- 
рирующих версий, аналогичных продуктов и аналогичных на- 
боров рисков качества системы), прогнозов отделов продаж 
и маркетинга о будущем использовании системы и других дан- 
ных заказчика. 


При создании этих объектов Эмма поняла, что два нужных ей компо- 
нента отсутствуют в тестовой среде. Во-первых, у нее не было достаточно- 
го числа лицензий виртуальных пользователей для инструмента нагру- 
зочного тестирования. Во-вторых, у нее имелись в наличии только две 
ограниченные системы управления иерархическими хранилищами. 
Эмма предполагала проводить тестирование для более крупных и разви- 
тых доступных систем. 

Она решила обсудить это с Джамалом, которого она нашла в тестовой 
лаборатории. Джамал беседовал с младшим тестировщиком, который 
рассказывал об обнаруженной им ошибке. 

“Классная ошибка, Эмамалини! Продолжай искать такие же нехоро- 
шие ошибки”, — сказал с улыбкой Джамал. Он повернулся к Эмме и спро- 
сил: “Насколько я понимаю, я могу для тебя что-то сделать?” 

“Изучая тестовую среду для тестирования производительности, я об- 
наружила, что ..., точнее, удивилась ситуации с управлением иерархиче- 
скими хранилищами”. Улыбка Джамала исчезла, как только заговорили 
на эту тему. Эмма торопливо продолжала: “Я помню все эти сентябрьские 
споры о серверах для иерархических хранилищ, но мне кажется, что нам 
не удастся загрузить систему несколькими интересными способами с по- 
мощью базовых моделей серверов, которые естьу нас”. 

“Расскажи мне подробнее о том, что ты не можешь протестировать”. 
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Воодушевленная таким началом, Эмма пустилась в подробное описа- 
ние некоторых тестов для проверки мощности и объема, которые требу- 
ют большей производительности и мощности процессоров, сети и жест- 
ких дисков, чем два сервера в лаборатории. Она описала два частных типа 
проблем производительности, о которых она читала и которые не удаст- 
ся проверить. 

“Хорошо, — сказал Джамал. — Что ты предлагаешь? Купить еще сервер? 
Или два?” 

“Я думала об этом, — сказала она и вручила Джамалу несколько напеча- 
танных страниц из Интернета. 

Джамал быстро прочитал содержание листков и присвистнул: “Несла- 
бые ценники”. 

“Да, — согласилась Эмма. — Но ошибки в этой части продукта могут по- 
ставить под вопрос жизнеспособность всего продукта”. 

Джамал думал минуту, потом медленно произнес: “Хорошо, я понял 
тебя. Ты знаешь, я тоже пытаюсь избежать рисков, поэтому не хочу ру- 
бить эту идею на корню, хотя мы уже рассматривали проблему ранее, — 
он сделал паузу. — Вот что мы сделаем. Давай устроим совещание и при- 
гласим на него Кейт Эрнандес, Дженни и всех людей из группы разра- 
ботки, кто отвечает за этот раздел системы. Ты расскажешь о своих со- 
ображениях по поводу технических рисков, мы выслушаем мнение 
системного архитектора, а затем заново оценим проблемы, связанные с 
бизнесом”. 

Совещание состоялось в этот же день после обеда. И Кейт, и Дженни 
поначалу были смущены тем, что сейчас в проекте вновь возник этот во- 
прос, как черт из табакерки. Однако Эмма и ведущий программист разде- 
ла управления хранилищами Боб Маршал быстро перешли к обсуждению 
серьезных технических проблем, и их руководители заблудились в дета- 
лях. Эмма и Боб пришли к общему выводу, что, хотя здесь есть некоторые 
риски, они ограничены ситуациями, когда используются файлы разме- 
ром, близким к максимальному, и определенные конфигурации дисковых 
массивов ВАШ. 

“Итак, — сказала Кейт. — Что вы думаете по поводу следующего предло- 
жения? Я попытаюсь найти одного или двух потенциальных заказчиков 
с подходящими файлами и конфигурациями, которые хотели бы провес- 
ти для нас бета-тестирование Суматры, такое решение подойдет?” 

Боб сказал: “Да, думаю, что вполне”. 

Эмма сначала колебалась, но потом возразила: “Что касается функцио- 
нальности, то безусловно, но врядли вотношении производительности и 
нагрузки. Эти виды тестирования требуют специальной подготовки. При 
случайном бета-тестировании такие тесты не будут выполнены”. 

Это породило параллельную дискуссию между Бобом, Дженни и Кей- 
том. 

Джамал, сидевший рядом с Эммой, быстро написал в своем блокноте: 
“Поедешь на место и проверишь там?” Она пожала плечами, покорно со- 
глашаясь, и написала снизу: “Хорошо, но это будет менее эффективно 
и медленнее”. 

Джамал вмешался в разговор: “Видишь ли, Кейт, мы могли бы вопло- 
тить эту идею в жизнь. Как ты думаешь, смогла бы ты убедить наших по- 
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тенциальных заказчиков разрешить Эмме посетить их рабочие места и 
выполнить там тестирование производительности?” 

Кейт посмотрела в окно, а потом сказала: " Да, я думаю, что мы сможем 
это сделать. Командировка обойдется дешевле, чем аппаратура”. Она 

посмотрела Эмме в глаза и сказала по-дружески и сулыбкой, но остава- 
ясь серьезной: “Не сомневаюсь, что Эмма не собирается пугать заказчи- 
ков рассказами об ошибках Суматры, не так ли?” 

“Нет-нет, я не буду этого делать", — быстро ответила Эмма, отрицатель- 
но качая головой. 

“Тогда договорились, — сказала Кейт. — У нас теперь два дела. Дженни 
и я будем искать одно или несколько подходящих мест для организации 
тестирования. Мы предоставим контактную информацию тебе, Джамал, 
до конца недели. Джамал, ты и Эмма должны определить, как выполнять 
ваши тесты на рабочих местах заказчиков. Поскольку мы будем использо- 
вать автоматизированные инструменты, я полагаю, что есть вопросы, 
связанные с материально-техническим обеспечением?” 

“Да, наверное, — ответил Джамал. — Возможно, мы должны также за- 
планировать еще одно совещание через пару недель, когда, по нашему 
мнению, эта часть системы тестов будет готова. Я бы предложил сначала 
завершить тестирование производительности внутри компании. Оно за- 
планировано, - он с минуту пошуршал своими записями, - когда мы полу- 
чим инкремент 3 в декабре, примерно 15-го числа. Таким образом, ориен- 
тировочная дата — начало января. Но думаю, что имеет смысл снова 
вернуться к этому вопросу 2-го декабря, чтобы посмотреть, где мы нахо- 
димся". 


№ этапа Этап Вьшолнено? 


4. Спроектировать, разработать, приобрести, усовершенство- 
вать, сконфигурировать и документировать средства тестиро- 
вания, тестовую среду и процесс вьшолнения тестов для вос- 
произведения определенных условий и проверки поведения 
системы с использованием выбранных методов тестирования. 
Усилить точность методов тестирования с помощью эмпири- 
ческих методов с учетом данных заказчика или пользовате- 
лей, отчетов о проблемах в эксплуатации (для ранних и конку- 
рирующих версий, аналогичных продуктов и аналогичных на- 
боров рисков качества системы), прогнозов отделов продаж и 
маркетинга о будущем использовании системы и других дан- 
ных заказчика. 


5. Если какие-либо элементы средств тестирования, тестовой М 
среды или процесса выполнения тестов оказались недоступ- 
ными в ходе выполнения этапа 4 из-за ограничений ресурсов, 
сроков и т.п., повторить этап 4 нужное число раз, чтобы при- 
способиться к этим ограничениям. 


Поскольку это предложение оказалось приемлемым для всех участни- 
ков совещания, Джамал сделал для себя три пометки. Во-первых, нужно 
было запланировать очередное совещание. Во-вторых, обновить деком- 
позицию работ и график проекта, включив две недели работы за предела- 
ми офиса для Эммы и, следовательно, ее недоступность в офисе. Он по- 
дозревал, что придется сократить часть тестирования, которое могло бы 
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быть выполнено, пока Эмма будет в командировке. Тем не менее он наде- 
ялся, что к тому времени Динеш сможет продолжить автоматизирован- 
ное тестирование, хотя и в сокращенном режиме. В-третьих, нужно было 
убедиться, что Эмма обучит Динеша выполнять автоматизированные тес- 
ты к моменту своего отъезда в январе. Эмма отправилась на свое рабочее 
место, чтобы закончить проектирование и разработку тестов для нагру- 
зочного тестирования с учетом дополнительного требования сделать их 
переносимыми. 

18 ноября, когда были написаны все тесты, Эмма приступила к провер- 
ке скриптов и данных. Сначала она организовала перекрестное рецензи- 
рование средств тестирования силами Лин Цу и Динеша. Это совещание, 
продлившееся пару часов, позволило выявить несколько дефектов, преж- 
де всего в скриптах. Эмма провела вторую половину дня после совещания 
за исправлением ошибок в скриптах. Поскольку число дефектов, обнару- 
женных в скриптах, было невелико, она решила не планировать еще одно 
перекрестное рецензирование для сделанных исправлений. Это было 
одно из решений, принятие которых сотрудниками группы тестирования 
в рамках существующих процессов Джамал поощрял. 

В настоящий момент в тестовой среде был установлен инкремент 2, 
в котором отсутствовал ряд ключевых свойств будущей версии. Написав 


‘несколько заглушек, Эмма увидела, что может выполнить скрипты и най- 


ти в них серьезные проблемы, если они там есть. Хитрость состояла 
в том, чтобы не помешать продолжающемуся тестированию. Она нашла 
окно в ночном графике выполнения тестов и настроила их запуск в это 
время. В результате были найдены еще ошибки в тестах, поэтому остав- 
шуюся неделю Эмма провела за исправлением и перетестированием 
скриптов, пока не почувствовала, что они готовы для применения к ин- 
кременту 3. Наконец Эмма поместила все связанные файлы: тестовые 
данные, тестовые сценарии, инструменты и т.п. — в проектный репозито- 
рий. На рис. 10.3 показан ход разработки тестовых сценариев для двух 
комплектов тестов по состоянию на среду, 20 ноября, когда Эмма завер- 
шала свою работу. 


№ этапа Этап Выполнено? 


6. Проверить систему тестов, используя статические (например, 
рецензирование) и динамические (например, выполнение 
тестов) методы. 


7. Поместить средства тестирования, описание процесса выпол- 
нения тестов, информацию о конфигурации тестовой среды, 
документацию о тестировании системы тестов (полученную 
на этапе 6) и всю прочую документацию, а также созданные 
файлы в библиотеку проекта или систему управления конфи- 
гурацией. Привязать версию системы тестов к версии систе- 
мы, предназначенной для тестирования. Вести контроль из- 
менений. 


В ходе разработки тестов Эмма также обнаружила ранее не рассмот- 
ренное требование — определение предельного числа файлов, которое 
может показать в перечне система управления документооборотом. Об 
этом была проинформирована группа управления изменениями (см. гла- 
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ву 16), которая приняла коллективное решение, что разумным числом бу- 
дет 1024, что соответствовало бы технической архитектуре и удовлетво- 
рило бы пользователей. 

Эмма, узнав о принятом решении, взяла таблицу анализа видов оши- 
бок и их влияния из репозитория документов и добавила два риска, свя- 
занных с этим ограничением. Первый относился к проблемам с обработ- 
кой каталогов нормального размера, например 100 файлов, второй — 
к проблемам на границе, 1024 файла. 


№ этапа Этап Выполнено? 


8. Обновить перечень рисков качества на основе новых знаний, 
полученных при разработке последних наборов тестов. Оце- 
нить покрытие рисков качества новой системой тестов. Вы- 
явить остающиеся непокрытыми риски качества, для которых 
рекомендовано тестирование. 


_ Ѕитаќга чарала алі рання Тез! Сазе тыт зенан 


Е різь Аср Різп Асар Бхес Енес _ 


КЕ У стей бонове 


_ 1000 оной _ 27 Я Я и 
1.001 ге Беміу 9/23 9/00 50 85 25 № 
12,092 84и Я Кељју: 9/23 9/20 80. 36 05 +5 
1098 Ром Веаду 9/25 5/20. 80 85 (оз 50. 
1004 Та Везду 9/23 9/28 30 85 | 86 я. 
1005 Ревбод Кемју 9/23: 9722 80 75 23 є 
1.006 Маларыі РИее _ Везду 10/2. 10/3 60 65 28 25. 
1.007 Ног Мапафей Ривз Безу 10/2. 9/30. 6р 49 50 
25068 РМ Сас Меч Кезіу 10/2 10;3 60 Е 25 
"1.009 М5 Свесісіп Еміл || ВеаФу 10/2  10/3 60 „35 39 
1.010 ОМЗ Ско Кеаіу 0/2 3/28 655: 55 35 | 35 
1.011 ОМ знай Міргале Отог Веаду 19/2 1071 62 55. Б 55 
1912 ОМЕ за /Міртаіє МОЇ. | Веабу 10/2 10/3 68 55 35 39 
3013. ОМУ соі Маса Обіле ему 10/2 3/5 Ба 7% 35 3» 
34044 БМ Ре тісплаїог :Веайу 3679 1016 50 а5 25 25. 
Бийе билиліму || К 2902 108 940 955 360 480 
12020 Ретўотидте, соні, Сарасду, алй Уобене Ж р ЕСИ й 
2001 бои Беғувг й о 1/8 178 160 155 25 90. 
_ 2002 МТ Веги : 5 8ю 
:2.003 іле багно 5 80. 
2004: АЇХ берег ав 80 
краб Нево _ з з» 
Р Зийе Зивиалу | за 400. 


Рис. 10.3. Выдержка из таблицы состояния дел по разработке тестов 
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Три решающих соображения 


В следующей главе более тщательно рассматриваются каждый из этапов 
процесса проектирования и разработки тестов. В оставшейся части этой 
главы предлагаю поговорить о трех важных соображениях относительно 
проектирования тестов. Это метод определения корректности результа- 
тов тестирования, виды документации, необходимые для системы тес- 
тов, и способы учета комбинаторных взрывов, которые могут возникнуть 
при подсчете числа возможных тестовых условий. Старшие специали- 
сты-тестировщики, проектировщики системы тестов и тест-менеджеры 
должны тщательно продумать все это до начала проектирования и разра- 
ботки тестов. Логика в рассмотрении этих проблем имеет существенное 
значение для создания высококачественной системы тестов в долгосроч- 
ной перспективе, а также для проведения качественного и эффективного 
тестирования в каждом проекте тестирования. 


Тестовые оракулы 


Тестовый оракул -- это система, метод или методика для предсказания 
или оценки корректности поведения системы, предназначенной для тес- 
тирования, в определенных условиях. Проблему определения подходя- 
щего оракула лучше всего показать на примере. Предположим, что вы хо- 
тите провести тестирование функции, возвращающей значение синуса 
аргумента, выраженного в радианах. Вы могли бы обратиться к курсу три- 
гонометрии для средней школы и вспомнить некоторые из известных 
значений синуса: 


51п(0) = 0 
о не, 
віп? 2 


УЗ 


И 
час?" 
р 

с 


Теперь вы можете воспользоваться тем фактом, что для углов от п/2 
до т радиан график функции синуса является зеркальным отражением от- 
носительно вертикальной прямой х = п/2, а для углов от л до 2л радиан 
график функции синуса является зеркальным отражением относительно 
оси абсцисс. В результате мы получаем 13 известных значений кривой, 
что позволяет нам обнаружить грубые ошибки. Чтобы получить более 
точные значения, необходимо аппроксимировать функцию синуса. (На- 
пример, разложение в ряд Тейлора представляет собой более точный и 
сложный способ аппроксимации функции путем увеличения числа чле- 
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нов ряда.) Однако чем больше членов мы добавляем, тем более сложным 
и, следовательно, подверженным ошибкам становится тестовый оракул. 

Тестовый оракул, способный предсказать корректное поведение сис- 
темы, предназначенной для тестирования, возможно, так же сложно раз- 
работать, как и саму систему. (При создании некоторых авиационных 
систем разрабатывается несколько версий программного продукта, а ре- 
зультаты сравниваются, чтобы определить, какой из многочисленных от- 
кликов систем является правильным.) 

Для упрощения задачи мы можем ограничить оракулы за счет игнори- 
рования определенных входных и выходных данных и вариантов поведе- 
ния системы. В приведенном примере я сначала игнорировал все ошиб- 
ки, за исключением грубых, а затем применил в качестве решения 
проблемы приближение рядами Тейлора высокого порядка, не учитывая 
ошибки низшего порядка. Но как быть в случае, если точность значений 
функции синуса является критической для верного нацеливания межкон- 
тинентальной баллистической ракеты или системы противоракетной 
обороны, которая должна вычислять курс перехвата для разрушения 
цели, летящей на сверхзвуковых скоростях? 

Если у вас имеется конкурирующая, действующая или еще какая-либо 
система, которая может имитировать какие-то или все варианты поведе- 
ния системы, предназначенной для тестирования, то у вас есть оракул. 
Например, однажды я работал в проекте тестирования системы для обра- 
ботки потребительских кредитов. В том проекте старая клиент-сервер- 
ная система стала оракулом для новой системы на основе браузера и ин- 
транета. Каждое заявление на кредит отправлялось в обе системы, 
а предлагаемые продукты, полученные в качестве результата обработки 
системами, сравнивались по возможности положительного решения, 
проценту, максимальному размеру ссуды, ежемесячной выплате и срокам 
кредита. Проблемами при таком подходе могут стать точность и кредито- 
способность. Если ежемесячную вьшлатууменьшить на 1 цент, заметит ли 
это клиент банка? И кто говорит, что действующая система работает вер- 
но? Насколько вероятно, что различие между выводом, полученным 
в системе, предназначенной для тестирования, и ожидаемым результа- 
том указывает на ошибку в оракуле? 

В некоторых случаях можно пренебречь точным прогнозом и дове- 
риться тестировщикам. Так, в примере с продуктом 5рееду\М/тиег мы мо- 
жем и, вероятно, должны оставить определенные аспекты, касающиеся 
разумных ожиданий пользователя, на усмотрение тестировщика. Если 
предполагается выдача определенного сообщения об ошибке, когда поль- 
зователь пытается перезаписать файл, предназначенный только для чте- 
ния, тестировщик, вероятно, может сделать вывод о том, что всплываю- 
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щее окно с сообщением об ошибке должно появиться на экране и быть 
активным. Более того, можно доверить тестировщику принятие решения 
о том, является ли сообщение об ошибке верным. 

Хотя этот вид разумного оракула обычно применяется к продуктам, 
предназначенным для конечного пользователя, уровень знания предмет- 
ной области тестировщиком для такого рода предсказаний варьируется. 
Большинство работающих методов исследовательского тестирования 
опирается в определенной степени на подходы, в которых в качестве ора- 
кула выступает тестировщик, хотя мой опыт исследовательского тестиро- 
вания также включает в себя применение в качестве оракулов эталонных 
систем. 

Даже точный оракул не сможет рассказать вам все, что вы хотите 
знать. В примере с синусом вычисления ряда Тейлора могут предоста- 
вить мне значение функции синуса, но они ничего не скажут о том, 
сколько для этого понадобится времени. В случае с системой противора- 
кетной обороны или прогноза погоды скорость вычислений так же важ- 
на, как и точность, поскольку результат, полученный после того как ра- 
кета достигнет цели или над территорией пройдет торнадо, никому не 
нужен! 

Понятие оракула пришло из греческой истории и мифологии. Ораку- 
лы предсказывали будущее, как правило, используя кости и внутренности 
домашних животных. Насколько мне известно, в процессе проектирова- 
ния, разработки и выполнения тестовых сценариев пока не пострадало 
ни одно животное, но это лишь потому, что у нас пока нет того количест- 
ва проблем, чтобы опробовать подобные решения в области проектиро- 
вания тестов. В тех случаях, когда необходимы точные оракулы, могут по- 
требоваться значительные усилия для их создания. 


Подходящая документация 


Некоторые тестировщики заполняют целые полки папками с документа- 
цией по тестированию. Другие не пишут практически никаких докумен- 
тов. Оба типа тестировщиков достигали успехов, и оба терпели серьез- 
ные неудачи. Между этими двумя экстремальными подходами находится 
целый спектр вариантов подготовки документации, приводящих как кус- 
пеху, так и к разочарованию пользователей. Каковы же соображения, ко- 
торые позволяют определить объем документации, которую мы должны 
подготовить? 

Когда мы документируем систему тестов, то обычно пытаемся точно 
описывать предстоящее тестирование. Это относится к тестовым сцена- 
риям, начиная с исследовательских и кончая сценариями, написанными с 
помощью скриптов. Тестовые сценарии, зафиксированные в скриптах, 
точно определяют действия, данные и ожидаемые результаты с незначи- 
тельной неопределенностью или без неопределенности. Точно докумен- 
тированная система тестов четко фиксирует конфигурацию тестовой 
среды также с минимальной неопределенностью. 


Более подробно о тестовых оракулах см. в статье Дуга Хоффмана (Рош; Нойтап) " Озіте 
Отасієз т Тея Ашотайот” на сайте ими. зоЁмагедиаНтутео95.сот. 
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Неопределенность, на первый взгляд, может показаться нежелатель- 
ным свойством средств тестирования. Это, безусловно, нежелательное 
свойство при определении требований или рисков качества. Однознач- 
ные средства тестирования поддерживают воспроизводимые тесты, что 
важно для регрессионного тестирования. Однозначные средства тести- 
рования также позволяют сделать интерпретацию результатов тестиро- 
вания менее зависимыми от человека, выполняющего тесты. Однознач- 
ные средства тестирования легко контролировать в том смысле, что 
другие могут изучить средства тестирования и точно понять, что было 
подвергнуто тестированию. 

Однако точные тестовые сценарии имеют и обратную сторону. Описа- 
ние точного тестового сценария обычно очень многословное и сложное. 
Сложность является не линейной, а экспоненциальной функцией разме- 
ра сценария, как известно нашим коллегам-программистам. Например, 
написание этой книги, которая примерно в 100 раз больше, чем мои ти- 
пичные отчеты о ходе тестирования, потребовало более чем в 1000 раз 
больше времени. Иногда у меня нет времени или ресурсов, чтобы доку- 
ментировать систему тестов с предпочтительной для меня точностью. 

Чем точнее документированы средства тестирования, тем точнее 
должно быть наше предвидение. Если в ходе разработки тестов я попыта- 
юсь точно описать, как будет работать пользовательский интерфейс, воз- 
можно, яувижу в процессе выполнения тестов, что ябыл неправ. Это при- 
ведет к переработке средств тестирования, что вряд ли является 
эффективным расходованием времени. Наконец, хотя точность способ- 
ствует повторному использованию тестов в регрессионном тестирова- 
нии, повторное использование предполагает также возможность сопро- 
вождения тестов. Чем более точно подготовлены средства тестирования, 
тем больше усилий требуется для их изменения, когда в систему вносятся 
изменения. 

Некоторая неоднозначность неизбежна. Представьте тест для ручно- 
го тестирования ЅреедуМтгіѓег, зафиксированный в скрипте. Можно ли 
следующий тестовый сценарий назвать однозначным? 


1. Запустить Ѕ5реедуМтгігег. Приложение должно открыть браузер. 
2. Создать новый документ. Должен появиться чистый документ. 


3. Набрать четыре строки текста. Проверить, что никакая часть тек- 
ста не утеряна. 


4. Сохранить файл. Проверить, что появляется окно "Сохранить как”. 


Заметим, что остается много вариантов неоднозначности. Какой брау- 
зер должен запустить ЅреейуМгіќег? Как мы узнаем, что приложение от- 
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крылось правильно? Как мы должны создавать новый документ: вызвав с 
помощью мыши меню или используя “горячие клавиши”? Что означает 
“чистый документ”: это чистый экран или сверху экрана должна быть па- 
нель инструментов, сбоку — полоса прокрутки и т.п.? Можно ли использо- 
вать различные шрифты для набора текста, или это означает добавление 
дополнительных тестовых условий? Как должно выглядеть окно “Сохра- 
нить как”? 

Я могу получить абсолютно точные и однозначные тесты для ручного 
или автоматизированного тестирования в виде скриптов, только если я 
могу предсказать заранее точный образ каждого экрана в сети, содержа- 
щего систему, предназначенную для тестирования, каждый бит памяти 
(оперативной памяти, кзш-памяти процессора, дискового пространст- 
ва, кэш-памяти диска, видеопамяти ит.д.) в каждой системе сети, содер- 
жащей систему, предназначенную для тестирования, и каждый сетевой 
пакет, проходящий по сети, содержащей систему, предназначенную для 
тестирования. И я должен уметь предсказать это в любой момент прове- 
дения тестирования. И даже в этом случае, я, вероятно, что-то упущу!. 

С одной стороны, следующие воздействия, соображения и факторы 
обычно способствуют увеличению объемов документации: 


= Потребность в регрессионном тестировании и воспроизводимо- 
сти тестов. Если мне нужно выполнять одни и те же тесты снова и 
снова, особенно если я должен многократно выполнять в точности 
те же тесты, мне потребуется точно документировать, что я делаю, 
как делаю, какие используются данные и что я ожидаю получить. 


= Потребность в проверяемости. Если я думаю, что мне потребуется 
отстаивать результаты проведенного тестирования (например, 
в суде), то важно точно фиксировать все, что я делаю. Например, 
при выполнении работ по контракту (оборонные заказы или заказ- 
ное программирование) или для законодательно регулируемых от- 
раслей (программные средства для здравоохранения и для управле- 
ния ядерными объектами в США) тестирование должно 
соответствовать определенным стандартам. 


и Использование автоматизации тестирования в настоящее время 
или в планах на будущее. Если я намерен автоматизировать часть 
функциональных или других тестов, которые ранее выполнялись 
вручную, наличие стабильного понятного процесса выполнения 
тестов, в котором используются четко определенные тестовые сце- 
нарии, способствует успешной автоматизации тестирования. 


= Потребность в формализации и стандартизации процесса тестиро- 
вания и документации. Формализованные процессы обычно ис- 
пользуют шаблоны и стандарты документации (см. главу 17), это оз- 
начает, что минимальный уровень документации определяется 
стандартом. 


1 М 
Несколько примеров тестовых сценариев разных степеней точности и документирован- 


ных разными способами можно найти в главе 3 моей книги “Мапаріпу е Теѕіпр Ргосеѕѕ, 
Ѕесопа Едійоп”. 


Гпава 10. Архимедова ванна 297 


. Уровень риска системы. Системы с повышенными требованиями 
к безопасности и с особым целевым назначением должны работать 
оченьточно при каждом их использовании. Педантичный подход к 
тестированию с тщательным документированием и применением 
перекрестных ссылок, как правило, является обязательным требд- 
ванием для достижения необходимого уровня доверия к системе . 


. Жесткие временные рамки для выполнения тестов/Однажды я дол- 
жен был выполнить серию тестов для проверки потенциальных 
проблем обработки данных в семействе серверов (ѕегуег Ғагт). Тес- 
ты предполагали очень точную установку серверных часов и загруз- 
ку определенных множеств данных, а затем оценивали, что проис- 
ходит в случае интересных событий, относящихся ко времени, 
например перехода от 31-го декабря 1999 г. к 1-му января 2000 года. 
Если хотя бы один из сценариев не выполнялся или выполнялся не- 
верно, когда наступали такие состояния, мы вынуждены были вос- 
производить, как минимум, соответствующий интервал времени. 
В некоторых случаях приходилось начинать с самого начала после- 
довательности. Точная документация способствовала более качест- 
венному выполнению этих хрупких тестов. 


. Сложность процесса выполнения тестов, тестовых сценариев 
и системы, предназначенной для тестирования. Мозг человека спо- 
собен обрабатывать одновременно только конечное число элемен- 
тов информации. Сложный тест, особенно тот, в котором порядок, 
время и данные должны быть четко организованы, требует исчер- 
пывающего документирования, чтобы убедиться, что нужные со- 
бытия происходят в нужное время и мы ищем ошибки в нужных 
местах. Например, тестовый сценарий для тестирования Интер- 
нет-приложения может включать в себя следующий шаг, связанный 
с ожиданием результата: "Подтвердите, что присоединенный к со- 
общению файл воспроизводится корректно". Но будетли шаг "Под- 
твердите, что приборы взлетно-посадочной полосы дают правиль- 
ные показания" достаточным, если мы проверяем летные качества 
лайнера "Конкорд"? 


. Необходимость фиксации знаний. Если тесты определены неточ- 
но потому, что всем известно, как выполнять эти тесты, это не вы- 
зовет проблем. Но тестовые сценарии и процедуры, которые нахо- 
дятся в голове у одного человека, порождают организационный 
риск и риск управления для группы тестирования. 


. Необходимость руководить неопытными тестировщиками и де- 
литься знаниями. При правильном руководстве определенные 
люди, которые были бы в противном случае недостаточно квали- 
фицированными для участия в тестировании системы, могут вне- 
сти свою лепту в процесс тестирования. Часть руководящих указа- 
ний может быть сделана в форме документированных тестовых 
сценариев. Документированные тестовые сценарии дают возмож- 


Ы Обратите внимание на главу 2 в книге “СотриіегКеіаіей Кізі Петера Ноймана (Регег 
Мецтал). 
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ность гораздо шире забросить сети в поисках тестировщиков и бо- 
лее успешно справиться с задачей поиска персонала для проекта. 
Документированные тестовые сценарии помогают людям вносить 
свой вклад в тестирование, в котором они вряд ли принимали бы 
участие в противном случае. Документированные тестовые сцена- 
рии позволяют разделить коллективное знание группы тестирова- 
ния с другими участниками проекта. 


Степень, в которой система тестов, сама является продуктом. Если 
система тестов является документом, передаваемым в какую-либо 
другую организацию, либо если по какой-либо причине она будет 
или может быть передана после заверщения тестирования, доку- 
ментирование позволяет упростить передачу знаний о том, как вы- 


`полнялось тестирование, а также об инструментах, данных, скрип- 


тах и другой работе. Хорошо подготовленная документация 
улучшает впечатление от выполненного тестирования и профес- 
сиональный имидж группы тестирования, которая это сделала. 


С другой стороны, следующие воздействия, соображения и факторы 
обычно способствуют уменьшению объемов документации: 


= Время и ресурсы, доступные для проектирования и разработки тес- 


товых сценариев. Малобюджетный проект с короткими сроками 
выполнения может заставить меня разработать меньше документа- 
ции, чем я предпочитаю. Время, которое я трачу на документирова- 
ние одного тестового сценария, — это время, которое я не потрачу 
на написание другого тестового сценария, поэтому, если я должен 
выбирать между тем, чтобы не тестировать некоторые области по- 
вышенного риска или оставить некоторые детали тестирования на 
усмотрение тестировщика, я выберу последнее. 


Квалификация тестировщиков, в первую очередь тех, кто выполня- 
ет тестовые сценарии. Менее квалифицированные тестировщики 
могут нуждаться в более детальном руководстве. 


Вопросы мотивации. Со временем тестировщики могут рассматри- 
вать выполнение одного и того же множества точно документиро- 
ванных тестовых сценариев как утомительное и немотивирован- 
ное занятие. Если другие факторы, в особенности, связанные 
с требованиями повышенной безопасности, требуют точного доку- 
ментирования, то обмен выполняемыми задачами и выделение вре- 
мени на исследовательское тестирование могут способствовать ре- 
шению проблемы. 


Вообще говоря, следующие воздействия, соображения и факторы свя- 
заны с надлежащим уровнем документирования различными способами и 
способствуют какуменьшению, так иувеличению объемов документации: 


ш Вопросы эффективности, повторного использования и сопровож- 


дения. Иногда я считаю, что некоторые части процесса тестирова- 
ния должны быть определены точно для того, чтобы сделать тести- 
рование эффективным. Например, как гарантировать, что два 
тестировщика не начнут по случайности одновременно выполнять 
один и тот же тест. В то же время я должен быть менее точным в де- 
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талях, относящихся к пользовательскому интерфейсу, если я счи- 
таю, что он станет объектом частых изменений. Если требуется 
точность, я могу сослаться на другую проектную документацию, а 
не повторять уже однажды зафиксированную информацию в тек- 
сте документов по тестированию. Аналогично, если доступны стан- 
дартные списки контрольных вопросов для определенных видов 
тестирования, я могу сделать ссылки на эти списки, а не воспроиз- 
водить их в системе тестов. 


и Ожидания и требования лиц, заинтересованных в тестировании 
и в проекте в целом. Иногда менеджеры проектов ожидают увидеть 
определенные типы или форматы документации. Иногда система 
тестов является передаваемым документом. Один раз я работал 
с клиентом, который пользовался услугами компании, поставляв- 
шей ему большую и сложную подсистему для интеграции с систе- 
мой, предназначенной для тестирования. Я сказал моему клиенту, 
что разумно сделать передачу тестовых сценариев, результатов 
и инструментов тестирования поставщика частью контракта, что- 
бы мы могли далее успешно провести тестирование этой подсисте- 
мы в контексте нашей системы. 


є Разумные представления и не очень. Некоторые тестировщики, 
программисты и менеджеры думают: “Ага, у нас нет времени на всю 
эту бумажную работу, мы должны просто направить все силы на тес- 
тирование”. Другие полагают: “Знаете, документация и стандарты 
представляют квинтэссенцию тщательных размышлений и про- 
шлого опыта, и мы должны следовать наилучшим практикам, что- 
бы минимизировать проектные риски”. В той или иной степени 
обе позиции могут быть верными. Я также считаю, что у меня есть 
некоторые пристрастия, появившиеся в результате предыдущего 
опыта, которые склоняют меня ко второму направлению мыслей. 
Вероятно, у вас есть собственные пристрастия, которые помогают 
вам, и вполне логично следовать подходам, которые работали рань- 
ше. Однако неправильно позволять вашим представлениям о доку- 
ментации (или о других практических вопросах) становиться столь 
жесткими, что вы начинаете следовать ритуалам, а не принимать 
рациональные решения. 


и Отсутствие знаний и хаос. Наконец, рассмотрим два нехороших, но 
не являющихся необычными фактора, оказывающих влияние на 
подходы к документированию. Некоторые просто не знают, как до- 
кументировать системы тестов, или не думают, что существуют раз- 
личные способы делать это. В некоторых проектах изменения явля- 
ются столь пронизывающими и непрерывными, что любая попытка 
зафиксировать что-нибудь приводит к появлению документа, кото- 
рый устаревает раньше, чем завершается его разработка. 


1 Сы. к примеру, достаточно подробный перечень списков контрольных вопросов для 
тестирования меб-приложений в отличном ресурсе Стива Сплайна (Зіеуе Ѕріаіпе) м Штефа- 
на Яскиля (Ѕіеѓар ]азНе!) “Тһе Иер Тепе Напабооі". 
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Столь же длинным, как только что приведенный, может быть список 
других воздействий, соображений и факторов, оказывающих влияние на 
вопросы документирования. Выбор различных уровней и подходов к до- 
кументированию тестирования является серьезным решением, которое 
требует тщательного рассмотрения всех сил, воздействующих на этот 
процесс. 


Комбинаторные взрывы 


Предположим, что у вас есть экранно-ориентированная система, напри- 
мер, программа, принимающая заявления на получение кредитов. По че- 
тырем экранам разбросано около 100 полей. Некоторые поля — двоич- 
ные, например “Объявляли ли вы о банкротстве в последние семь лет?” 
Некоторые поля допускают целочисленные значения, например “Сколь- 
ко лет вы живете по этому адресу?” Есть несколько полей, принимающих 
е текст, например “Введите фамилию | вашего работодате- 

я”. Получается более 1030 ‚ вероятно, даже больше 1060, потенциально ин- 
о комбинаций данных, которые могут быть введены в это множе- 
ство экранов, хотя большое число бессмысленных и невозможных 
комбинаций можно удалить. Например, если заявитель отвечает “Нет” на 
вопрос, имеет ли он неуплаченные ссуды на автомобиль, последующие 
поля по поводу неуплаченной ссуды на автомобиль: ежемесячные выпла- 
ты, остаток долга, срок и наименование кредитора — будут наверняка 
пустыми. Даже если природа приложения такова, что большинство этих 
бессмысленных комбинаций можно устранить, скажем, 99. 999% потен- 
циальных комбинаций данных, все равно останется более 1026 .Даже если 
вы сможете найти способ обработать все эти данные в течение некоторо- 
го реального периода времени, вы наверняка не сможете найти время 
проверить все ожидаемые результаты. 

Другой пример: комбинаторный взрыв возникает, когда вы тестируе- 
те автономное приложение для ПК, которое работает в различных верси- 
ях основной операционной системы и на различных платформах. Каж- 
дый вариант операционной системы, включая служебные пакеты и 
патчи, комбинируется со всеми поддерживающими приложение плат- 
формами и всеми возможными сосуществующими программами, что в ре- 
зультате дает огромную матрицу возможных конфигураций тестовой сре- 
ды. Также может существенно различаться порядокустановки служебных 
и сосуществующих программ. Ошибки в сосуществующих программах на 
персональных компьютерах на платформе У/іпдомз обычно называют 
адом динамически присоединяемых библиотек (011 ће). Библиотеки обще- 
го доступа перекрываются новой версией при установке дополнительной 
программы, эта новая программа оказывается несовместимой с ранее ус- 
тановленными программами, которые ее должны использовать, что в ре- 
зультате делает ранее установленные программы неработоспособными. 


По электронной почте я обсуждал эти вопросы с Грегори Дейчем (Стерогу Раїсі), Рос- 
сом Коллардом (Козз СоПага), Майклом Болтоном (Місрає! Вокоп) и Робином Голдсмитом 
(Вот СоЇаѕті), они помогли сделать более четкими мои представления об этой области. 
Благодарю их за потраченное время и признаю их вклад в этот раздел книги. 
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Если у вас имеется 100 программ и вы хотите провести исчерпывающее 
тестирование влияния порядка установки этих программ, то вы получите 
примерно 9х10**157 условий для тестирования. 

Эти два примера иллюстрируют общую проблему при проектировании 
тестов — комбинаторный взрыв. Были созданы различные методы сокра- 
щения этих больших и неуправляемых наборов тестов до разумного разме- 
ра. Подробное обсуждение этих методов выходит за рамки книги, поэтому 
я кратко расскажуо методах, а затем укажу источники для дальнейшего изу- 
чения, если вы посчитаете какой-либо из этих методов полезным. 

Что касается комбинаций конфигураций, метод, которым я обычно 
пользуюсь, включает в себя три этапа. Во-первых, я выявляю важные кон- 
фигурации. Конфигурация считается важной, если есть вероятность 
ошибок в ней (технический риск) и конфигурация является распростра- 
ненной (бизнес-риск). Во-вторых, я распределяю различные тестовые 
сценарии, которые предполагаю выполнять, по различным конфигура- 
циям. В-третьих, я планирую изменять конфигурацию каждый раз при по- 
вторном выполнении теста в последующих тестовых циклах . 

Другое семейство методов, применяемых к комбинаторным взры- 
вам, называют по-разному: планирование экспериментов, методы Тагу- 
чи, дробные двухфакторные (реже — трехфакторные) планы и ортого- 
нальные массивы. Эти методы обычно рассматривают взаимодействия 
между парами или тройками различных факторов и выбирают неболь- 
шое подмножество из потенциально огромного множества, которое 
покрывает интересные взаимодействующие пары. Название “ортого- 
нальные массивы” происходит от того, что метод предполагает по- 
строение массива, состоящего из столбцов, каждый столбец представ- 
ляет один из факторов или переменных, т.е. полей на экране. 
Взаимодействующие пары этих факторов или переменных, исключая 
неверные, недостижимые или невозможные комбинации, заполняют 
столбцы, пока каждая взаимодействующая пара не появится хотя бы в 
одной строке массива. 

О методе Тагучи написано множество книг, хотя они не посвящены 
специально программным продуктам. Мне известны две статьи на эту 
тему, касающиеся исключительно программ. Одна из них написана Гени- 
чи Тагучи (Сепісіі Табисһі) и Раджешом Джагалумом (Ка]езВ Јаршит) 
"Ргіпсірієз ої Тарисһі Мешодз Бог Зоймаге Тезіїпр". Другая написана Эл- 
фрид Дастин (ЕНпеде Ризііп) “Ог‹һоропаіу Ѕреакіпр”. Возможно, три из 
наиболее понятных описаний этого метода в применении к программно- 
му обеспечению можно найти в книге Рика Крейга (ВісК Сгаір) и Штефа- 
на Яскиля (Ѕ‹еѓап ]аз Же!) “будетайс Зойшате Тезійпр", на сайте Джеймса Баха 
Уатез Васі) и в книге Ли Копленда (Іее Сореїапа) “Маяептпр 5о/їшате Те 
Дезірт". 


1 Этот метод описан более подробно в главах 3 и 5 моей книги “Мапара (Фе Теѕіпр 
Ргосеѕѕ, Ѕесопа Е оп”. 


2 Статья Тагучи и Джагалума появилась в материалах Второго всемирного конгресса по 
вопросам качества программного обеспечения (Руосеейіпоу оў Ше Ѕесопа Мотій Сопртеѕѕ јот 
Зойшате Фиа 1), а статья Дастин была опубликована в журнале "5о/їшате Теѕйпр апа Оиайу 
Епатеетт;”, УоТате 3, 1554е 5 (Зер/ Осі 2001). Крейг и Яскиль рассматривают вопрос в гла- 
ве 6 своей книги. Инструменты для создания тестов по методу ортогональных массивов 
можно найти на улум/.заціяйсе.сот, мими. рБадКеаззос1атез. сот и мим Газой. сот. 
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К комбинаторным взрывам относится также метод под названием 
“анализ эксплуатационной безопасности” (Багаг4 ара[уѕіѕ) или “причин- 
но-следственный анализ” (саџѕе-апа-еҝесі апа1уз15). Сначала выделяются 
определенные типы проблем (нежелательных эффектов), например пе- 
резапись разделяемой динамической библиотеки несовместимой биб- 
лиотекой, и делается попытка вычленить все возможные пути (корен- 
ные причины), которые могут к этому привести. В результате 
тестирование может быть направлено на проверку только тех комбина- 
ций из огромного числа возможных, которые могут вызвать отказы и 
сбои в системе. Можно найти описание конкретного случая примене- 
ния этой идеи к тестированию программ в статье Ясухаре Ниши 
(Уазираги №151) “Кезоигсе Раї Теѕііпр: А Егатемогі бог Дезідп об Зузгет 
Тезцир”.. 

Аналогично можно применять различные типы разделения на классы 
или области эквивалентности. С помощью этих методов огромное множе- 
ство комбинаций разделяется на небольшое множество областей. Мы 
считаем, что внутри каждой области система будет работать со всеми ком- 
бинациями одинаково. Внутри областей есть несколько интересных то- 
чек; тестирование в этих точках показывает, является ли работа системы 
со всеми элементами области, которую представляют эти точки, коррект- 
ной. Способ, с помощью которого система, предназначенная для тести- 
рования, определяет или реализует эти области, может сделать этот ана- 
лиз и результирующее множество тестов проще или сложнее. Поэтому 
применение правильного подхода непосредственно в период проектиро- 
вания архитектуры программы, вероятно, позволит упростить тестиро- 
вание. Борис Бейзер подробно разбирает эту тему в своих книгах "5о0/їшате 
Теѕйпр Тесһтідиеу' и“ Віасі-Вох Тейт”. То же вы можете найти у Ли Коплен- 
да в "Мазіегіту 5о/їшате Тезі Пеѕірт”. 

Наконец, еще один метод применяет для отбора конкретных набо- 
ров данных сценарии использования системы (џиѕе саѕеѕ), парадигмати- 
ческое представление последовательности выполняемых действий в 
комбинации с анализом граничных значений. Этот подход я использо- 
вал с переменным успехом для тестирования экранно-ориентированной 
системы с множеством полей для обработки заявлений на получение 
кредитов при линейном характере последовательности выполняемых 
действий. Большая часть работы системы — есть обработка полей экра- 
нов и самих экранов в строго заданной последовательности, что позво- 
ляет нам исключить огромное множество возможных вариантов поряд- 
ка ввода данных, которые маловероятны и даже невозможны при 
реальном использовании системы. Росс Коллард (Коѕѕ СоПага) дал от- 
личное описание этого метода в статье “Теѕг Дезієп: Оеуорше Тез 
Сазез гот Озе Сазез". 


1 
Статья Ниши была впервые опубликована в материалах Второго всемирного конгресса. 


по вопросам качества программного обеспечения Руосеейіпрз оў іе Зесопаї Мота Сопртеѕѕ јот 
Зойшате диа у), а затем перепечатана в журнале “боймаге Опаісу Ргобеззіопа!", Уоате 3, 
155це 3 (Јипе 2001). Диаграммы причинного анализа рассматриваются в книге Каору Исика- 
вы (Каоги [5 Кама) “Сшае іо Оцаїну Соптог. 


2 Статья Колларда была впервые опубликована в журнале "Зо/їшате Тейт апі Оиайу 
Епоіпеетіпо", Уоїате 1, 155ще 4 (ЛИ/Аце} 1999) и может быть в настоящее время найдена на 
му. НсКупи5.сот. 
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От технического взгляда к точке зрения 
менеджмента 


В этой главе проектирование и разработка тестов рассмотрены с техниче- 
ской точки зрения. Мы изучили один набор тестов из основного примера 
книги и увидели, как Эмма применяет наилучшие способы проектирова- 
ния и разработки тестов, чтобы выстроить свою часть системы тестов. Мы 
обсудили некоторые важные практические соображения, касающиеся 
проектирования и разработки тестов. Однако нам еще нужно исследовать 
процесс целиком, более общую картину и точку зрения менеджмента. Если 
время и деньги были бы неограниченными, мы могли бы написать идеаль- 
ную систему тестов, которая рассказала бы нам все о качестве системы, 
предназначенной для тестирования. Ноу нас есть реальные ограничения. 
В следующей главе мы рассмотрим эти ограничения, а затем исследуем 
процесс проектирования и разработки тестов глобально. 


ГЛАВА 11 


Заполнение ванны: тестовое 
покрытие и качество системы 
тестов 


В этой главе мы завершим исследование процесса проектирования 
и разработки системы тестов. Прежде всего мы рассмотрим ключе- 
вой момент: как понять, когда разработано достаточно тестов. Различ- 
ные способы, с помощью которых мы можем измерять полноту тестиро- 
вания, обычно называются тестовым покрытием. За этой простой фразой 
скрывается бесконечное количество методов. Все эти взаимодополняю- 
щие методы позволяют специалистам-тестировщикам оценить пути, по- 
средством которых тесты нацеливаются и не нацеливаются на опреде- 
ленные разделы, интересующие тестировщиков. 

Полнота тестирования — это, безусловно, один из важных аспектов хоро- 
щей системы тестов, но есть и другие. Я завершаю эту главу рассмотрением 
всего процесса проектирования и разработки системы тестов. Как мы узна- 
ем, что процесс качественный? Как мы можем перейти от текущего процес- 
са, который, возможно, не работает, к более качественному процессу? 


Краткий обзор методов анализа 
тестового покрытия 


Перед тем как мы вернемся к нашему другу Джамалу и его частным про- 
блемам с тестовым покрытием, позвольте кратко рассмотреть некоторые 
общие методы тестового покрытия. На нескольких страницах невозмож- 
но разместить исчерпывающее введение в сложную и многообразную 
тему тестового покрытия. Тем не менее я рассмотрю идеи, которые ис- 
пользуются в основном примере книги. 

Я подготовил ссылки на случай, если читатель захочет исследовать 
тему более подробно. Если вы и ваша группа в основном занимаетесь по- 
веденческим тестированием, не слишком тревожьтесь, если вы не поня- 
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ли всех деталей материала, посвященного структурному покрытию. Я не 
случайно рассматриваю эти методы тестового покрытия, поскольку они 
наиболее широко используются на практике. 

Когда говорят о получении хорошего тестового покрытия, интуитив- 
но имеют в виду, что система тестов нацелена на большинство тестовых 
условий для тестируемой системы или, по крайней мере, на болыную 
часть важных тестовых условий. Если это определение выглядит нечет- 
ким, то лишь потому, что так оно и есть на самом деле. Нечеткое, неточ- 
ное применение фразы “тестовое покрытие” является обычным явлени- 
ем. Попробуем снять часть этой неопределенности, чтобы можно было 
понять, о чем речь, поскольку я использую это словосочетание для обо- 
значения четкого и измеряемого понятия. 

Для начала скажем, что анализ тестового покрытия — это отображе- 
ние тестов на некоторое свойство системы, предназначенной для тести- 
рования. Свойства могут быть поведенческими (т.е. описывать то, что 
система должна делать), структурными (т.е. описывать то, как работает 
система) или некоторой комбинацией этих двух типов. Механизм, с помо- 
щью которого происходит отображение, позволяет провести количест- 
венную оценку тестового покрытия. 

Для покрытия поведения (или черного ящика) представим, что для ка- 
ждого выявленного риска качества мы определяем по крайней мере один 
тест. Считая, что мы хорошо провели анализ рисков качества, а затем так- 
же хорошо справились с проектированием и разработкой тестов, мы по- 
крыли, таким образом, риски качества. 

Мы можем измерить это покрытие с помощью матрицы, где по одной 
оси представлены тестовые сценарии, а по другой риски качества (см. 
ниже). Для каждого пересечения тестового сценария и риска качества, 
т.е. каждого элемента матрицы, мы можем измерить покрытие риска ка- 
чества с помощью данного тестового сценария . 

В дополнение к трассировке рисков качества мы можем отслеживать 
покрытие требований, поддерживаемых конфигураций и сценариев ис- 
пользования системы. Если мы извлекаем риски из требований, конфигу- 
раций и сценариев использования, то покрытие рисков качества будет 
объединением множеств покрытий этих трех областей. 

Документы, аналогичные анализу рисков качества и спецификации 
требований, являются статическими моделями функционирования сис- 
темы. Мы также можем построить другие модели поведения системы. 
Эти модели могут фиксировать потоки и виды данных системы, последо- 
вательность экранов, состояния, в которых может находиться система, 
и последовательность их обработки. Эти модели графические, с узлами 
и связями между ними, построенные графы можно трансформировать 
в таблицы. Можно провести оценку покрытия относительно этих моде- 
лей, проверив, что каждому узлу и каждой связи в графе соответствует 
тестовый сценарий“. | 


Рик Крейг (Кіск Сгаір) и Штефан Яскиль (Ѕіеѓап ]аз Не!) в книге “Зузетайс 5о/їшате Тезійпр" 
дают неплохое описание этого метода, используя понятие реестра целей тестов (їеѕі 
оБесйуе іпуепхогіеѕ). 


2 Этот метод подробно излагается в книге Бориса Бейзера “Тестирование черного ящика”. 
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Некоторые измеряют покрытие бинарно: есть или нет, 0 или 1, ста- 
вят контрольную метку или нет. Однако более точная оценка покрытия 
требует от нас понимания, в какой степени тесты нацелены на интере- 
сующие нас области системы. Точность измерений степени покрытия 
ограничена, но выделение сильных и слабых связей между тестами и ин- 
тересующей нас областью (в этой книге — рисками качества) является 
неплохим началом. 

Оценки покрытия поведения системы, например покрытия требова- 
ний, наибодее тесно связаны (явно или неявно) с бизнес-рисками. В ка- 
кой степени и какие отказы могут подвергнуть риску ценность системы? 
Мы должны проверить каждую из областей пропорционально влиянию 
сбоя на возможность использования системы. 

Еще один вопрос, который мы могли бы задать, относится к техниче- 
скому риску. Какова вероятность того, что произойдут определенные 
сбои? Мы также должны проверить каждую из областей пропорциональ- 
но каждому риску. 

Чтобы оценить покрытие технических рисков, можно обратиться 
к элементам архитектуры. Можно построить модель системы, а затем 
проверить покрытие этой модели. Простое выявление основных подсис- 
тем программного и аппаратного обеспечения в большой системе, а так- 
же данных и управляющей логики программы позволяет получить модель 
для оценки покрытия тестами технических рисков. (Тестовое покрытие, 
проектирование и разработка тестов, основанные на этих видах инфор- 
мации, иногда называются тестированием серого ящика.) Переход к следую- 
щему этапу ианализ наиболее вероятных сбоев каждой подсистемы и каж- 
дого интерфейса между двумя и более подсистемами, а затем 
сопоставление с этими элементами определенных тестовых сценариев 
обеспечивают более полное покрытие (см. раздел “Выполнение тестов” 
главы 3). | 

Продолжая движение к более низким уровням системы, отдельным 
строкам исходного кода, мы можем посмотреть на технические риски 
с точки зрения сложности. Поскольку человеческий мозг способен опе- 
рировать ограниченным числом объектов одновременно, то чем слож- 
нее фрагмент кода, тем более вероятно, что программист допустил в нем 
ошибку. В 70-х гг. прошлого века Томас Маккейб (Тһотаѕ МсСабе) приду- 
мал способ измерения сложности, он ввел понятиє "цикломатическая 
сложность". Для цикломатической сложности каждая точка принятия ре- 
шения, место, где программа может выбрать один из двух и более путей 
на основе определенного условия, увеличиваєт сложность кода. Чем 
сложнее фрагмент кода, например функция или метод, тем более тща- 
тельному тестированию он должен подвергаться (если не происходит 
восстановления структурной схемы и алгоритма работы по исходным 
текстам). 


1 РА з 
Дополнительно об измерении цикломатическом сложности Маккейба можно прочитать 


во введении в цикломатическую сложность в "Зоймаге Епріпеегіпр Іпѕііси(е!ѕ боймаге 
Тесһпоіору Кемем”, Бир:/ /милм.зе.сти.еди/зи/ЧезсирИопз/суотайс_Ъо4ду.Вит!. Мож- 
но также посмотреть исчерпывающее введение в измерение с подробной библиографией 


в “Епсусіорейіа оў 5о/їшате Епріпегтітр, Зесопа Енот". 
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Маккейб ссылается на множество тестов, которое увеличивается в раз- 
мерах с ростом цикломатической сложности, как на базовые тесты (Баѕіѕ 
гсеѕіѕ). Это такой вид тестового покрытия, где по крайней мере один тест 
проверяет передачу управления в каждой точке принятия решения и в ка- 
ждом операторе между каждой точкой решения. Число базовых тестов 
для функции обычно такое же, как сложность функции. Покрытие базо- 
выми тестами — это один из видов покрытия кода, которое измеряется 
статически с помощью анализа кода и базовых тестов. 

Чаще измерение покрытия кода происходит динамически, благодаря 
отслеживанию управляющей логики программы в ходе тестирования, 
Обычно инструменты по измерению тестового покрытия позволяют по- 
лучить процент строк кода, выполненных в ходе прогона всего набора 
тестов. Грубые инструменты, например профайлеры, позволяют узнать, 
выполнялись ли функции . Просматривая, что не было выполнено в ходе 
тестирования, тестировщики и менеджеры могут решить, нужно ли уси- 
ливать тесты для смягчения определенных технических рисков. 

Обычно тестировщики поведения системы, особенно в независимых 
группах тестирования, фокусируют свои усилия на покрытии поведения, 
атестировщики структуры, особенно программисты, обычно концентри- 
руются натестовом покрытии структуры. Однако при таком подходе мож- 
но упустить возможности заполнения пропусков втестировании. Если ис- 
пользуются методы черного ящика для проектирования и разработки 
тестов, последующее применение анализа покрытия поведения системы 
может сообщить только о том, не забыли ли мы что-нибудь. В то же время 
важно знать, не оставил ли метод покрытия поведения системы сущест- 
венные технические риски без покрытия. Последнее означает, что при- 
менение методов анализа тестового покрытия структуры системы к мно- 
жеству тестов, подготовленному средствами анализа поведения системы, 
может стать эффективным методом обнаружения и устранения пропус- 
ков в покрытии. 


1 Оказывая услугу всему сообществу тестировщиков, главный консультант компании Тејаѕ 


СопзШитв Данни Фот (Раппу Кацріг) поддерживает обширный перечень инструментов тес- 
тирования, включая инструменты анализа кода, на сайте ууу .(ејаѕсопѕиііпе.сот. 
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Джамал оценивает покрытие 


Ноябрь приближался к концу, и разработка тестов близилась к заверше- 
нию, лишь немного отставая от графика. Джамал был рад заметить, что 
он завершил изучение статистики покрытия рисков качества. По мере 
того как Эмма, Лин Цуи Динеш разрабатывали тесты, он просил их оце- 
нить релевантность тестов по отношению к каждому из рисков качест- 
ва, определенных в ходе анализа ЕМЕА. Для оценки релевантности ис- 
пользовались четыре категории, которым были присвоены числовые 
значения. 


ш 0 — покрытие отсутствует. Тестовый сценарий не затрагивает пове- 
дения системы, связанного с этим риском качества, и, таким обра- 
зом, не воспроизводит связанных с поведением функций. 


ш 1-- вероятностное покрытие. Тестовый сценарий затрагивает не- 
значительный пример поведения системы, связанного с данным 
риском качества, что приводит к случайному поиску связанных 
с риском сбоев. 


и 3 — сбалансированное покрытие. Тестовый сценарий затрагивает 
существенный пример поведения системы, связанного с данным 
риском качества, что приводит к широкому поиску связанных с рис- 
ком сбоев. 


и 9— подробное покрытие. Тестовый сценарий затрагивает сущест- 
венный пример поведения системы, связанного с данным риском 
качества, и глубоко исследует поведение в этом месте системы, что 
приводит к расширенному поиску связанных с риском сбоев. 


По мере получения этой информации о тестовых сценариях Джамал 
переводил детальное представление о покрытии на более высокий уро- 
вень системного тестирования. Он делал это с помощью таблицы, в кото- 
рой с левой стороны сверху вниз были перечислены все тестовые сцена- 
рии, разработанные его группой. В верхней части таблицы он выписал 
основные категории рисков, их идентификаторы и значения приорите- 
тов рисков из таблицы анализа рисков качества (видов ошибок и их влия- 
ния). Для каждого пересечения тестового сценария и риска он ввел значе- 
ние релевантности, полученное при оценке покрытия тестировщиком, 
который разрабатывал данный тестовый сценарий. Фрагмент этой таб- 
лицы показан на рис. 11.1, где во второй строке сверху записаны иденти- 
фикаторы рисков качества. 

Джамал заметил, что единственный риск качества, который остался 
непокрытым или находится за пределами уровня тестирования, опре- 
деленного в строке “Рекомендованные действия” в таблице ЕМЕА, от- 
носится к удобству использования. "Да, — понял он, — я забыл добавить 
набор тестов для этого, хотя мы даже выделили средства на изучение 
удобства использования. Я должен пойти в бухгалтерию и узнать, ут- 
вержден ли заказ на закупку по тому контракту”. Он добавил набор 
тестов в таблицу отслеживания тестов и обновил таблицу покрытия 
рисков. Наконец он положил обновленный документ в проектный ре- 
позиторий. 
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Рис. 11.1. Фрагмент результатов анализа покрытия рисков качества 
в проекте “Суматра” 


№этапа Этап Выполнено? 
8. Обновить перечень рисков качества на основе новых знаний, 


полученных при разработке последних наборов тестов. Оце- 
нить покрытие рисков качества новой системой тестов. Вы- 
явить остающиеся непокрытыми риски качества, для которых 
рекомендовано тестирование. 


9. Повторить этапы 2 -- 8, пока не будут покрыты все риски каче- 
ства, для которых рекомендовано тестирование. Убедиться, 
что документация о рисках качества обновлена в проектном 
репозитории. Если ограничения бюджета и сроков вынужда- 
ют прекратить разработку тестов, подготовить отчет о непо- 
крытых рисках качества и направить его руководству. 


4 


В ходе планирования комплексного тестирования Джамал, Лин Цу 
и Змма совместно с Дженни Кауфман и єє ведущими программистами 
провели анализ технических рисков, связанных с сетевой и системной 
архитектурой. Данный анализ рисков определяет порядок и объем тестов 
комплексного тестирования, которые должны быть спроектированы и 
разработаны инженерами-тестировщиками. Замыкая круг, Джамал по- 
просил Эмму, ведущего инженера по комплексному тестированию, про- 
верить каждый сценарий для интеграционного тестирования в отноше- 
нии покрытия технических рисков. Теперь, с точки зрения архитектуры 
верхнего уровня, Джамал мог быть спокоен за покрытие технических 
рисков в ходе комплексного тестирования. 
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“Хорошо, — думал Джамал, — а что у нас происходит с проблемами ар- 
хитектуры низкого уровня и ее реализации? Как насчет проведения ана- 
лиза покрытия структуры в ходе раундов комплексного и системного тес- 
тирования? Что будет и что не будет протестировано с точки зрения 
покрытия кода? Мы немного вышли за временные пределы проектирова- 
ния и разработки тестов. Однако по выделенным на эту работу часам все 
в порядке — получается около 30 часов недоработки”. Джамал решил рас- 
смотреть три варианта: 


1. Приобрести инструмент оценки сложности кода, научиться им 
пользоваться, измерить сложность системы и увеличить тестовое 
покрытие особенно сложных областей. 


2. Приобрести инструмент оценки сложности кода, научиться им 
пользоваться, измерить покрытие операторов и ветвей за счет тес- 
тирования системы, а затем заполнить пробелы, связанные с повы- 
шенным риском. 


3. Использовать встроенные профайлеры, которые имеются в неко- 
торых средах разработки, или бесплатные инструменты покрытия 
кода, чтобы попытаться провести недорогое измерение покрытия 
на верхнем уровне. 


Джамал понимал, что для вариантов 1 и 2 нет ни времени, ни денег. 
Если бы разработка тестов не вышла за пределы бюджета и у Эммы, Лин 
Цу и Динеша было много свободного времени, он, вероятно, мог бы вы- 
брать один из этих вариантов. Однако он мог попросить Динеша, кото- 
рый показал, что способен быстро обучаться, и имел некоторый опыт по- 
крытия кода, посмотреть вариант 3. Если ничего не выйдет, не страшно, 
но, возможно, есть некоторые недорогие и не оказывающие сильного 
влияния пути решения проблемы. Он направился к Динешу, чтобы обсу- 
дить с ним эту идею. 

“Привет, Динеш, есть минутка?” 

"Да, Джамал, что случилось?” — сказал Динеш, поворачиваясь к Джамалу. 

“Я знаю, что к настоящему времени ты завершил разработку скриптов 
для тестирования надежности и стабильности и до февраля не будешь на- 
чинать разработку скриптов для функционального тестирования систе- 
мы управления документооборотом. Я вот думаю, можно ли поручить 
тебе побочный проект, помимо руководства выполнением тестов?” 

“Ещебы!” , 

Джамал сказал: “Я закончил просматривать результаты анализа покры- 
тия рисков качества — ты знаешь, я запрашивал значения релевантности 
по мере написания тестов, — ианализа технических рисков, который про- 
вела Эмма в ходе подготовки к комплексному тестированию. С точки зре- 
ния тестирования черного и серого ящика, у нас все хорошо”. 

“Это хорошо”, — вставил, кивая, Динеш. 

“Итак, — продолжал Джамал, — мне не известна только одна информа- 
ция о покрытии: степень покрытия структуры, или белого ящика. Какой 
объем кода мы тестируем? Я знаю, что группа Дженни при проведении 
модульного и компонентного тестирования имела стандартное значение 
90% и выше. Однако это другой тип тестирования. Мы могли бы найти 
различные виды дефектов, покрывая тот же код нашими тестами. В об- 
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щем, я хочу попросить тебя о следующем. Во-первых, можешь ли ты най- 
ти инструмент для быстрого и недорогого анализа покрытия кода? Воз- 
можно, бесплатный инструмент покрытия кода или что-то подходящее, 
что имеется в среде разработки”. 

“Должен ли он быть сложным? — спросил Динеш. — Я имею в виду, 
должны ли мы уметь измерять только покрытие операторов или нам нуж- 
но измерить покрытие условий и путей?” 

“Вообще-то, — ответил Джамал, — я бы предпочел получить оценку по- 
крытия условий и путей, но подозреваю, что нам придется остановиться 
на покрытии операторов или, возможно, только на покрытии функций. 
Но яоткрыт для любых твоих предложений. Если бы ты смог провести не- 
большое исследование и предложить несколько вариантов в ближайшие 
3 — 4 дня, мы бы приняли решение”. 

“Хорошо, — ответил Динеш. — Думаю, что это выполнимо”. 

“Вторая часть поручения — выполнение анализа покрытия кода. Воз- 
можно, тебе потребуется помощь кого-то из группы сборки версий Ясухи- 
ро, чтобы подготовить инструментированные тестовые версии, подходя- 
щие для измерений, а затем установить их в тестовую среду. Чтобы 
узнать, какое у нас имеется покрытие, мы должны выполнить все тесты. 
Если мы сможем двигаться достаточно быстро, это может быть сделано 
в ходе раунда 3 комплексного тестирования и раунда 4 системного тести- 
рования. Я бы не хотел делать это слишком поздно, поскольку всегда есть 
вероятность, что инструментированная версия программы ведет себя 
иначе, чем обычная версия”. 

“Понятно”, — согласился Динеш. 

“Наконец, когда мы выявим пробелы в покрытии (я не сомневаюсь, 
что мы их обнаружим), мне бы хотелось, чтобы ты поработал вместе с 
Эммой и Лин Цу над усилением тестирования. Думаю, что какая- 
никакая, но польза от этого будет, в зависимости от того, сколько време- 
ни и денег останется, по крайней мере, мы сможем уделить внимание 
элементам наибольшего риска. Вероятно, ты смог бы сравнить наше по- 
крытие с покрытием, полученным при компонентном и модульном тес- 
тировании, чтобы понять, есть ли куски программы, которые никто не 
проверял”. 

“Понятно, — ответил Динеш, — думаю, что это интересное поруче- 
ние. Я начну после обеда, сразу после того, как завершу анализ некото- 
рых результатов тестирования, которые прислала Эмамалини сегодня 
утром”. 

“Хорошо. Встретимся завтра, чтобы посмотреть, как у тебя дела?” 

“Хорошо”, — ответил Динеш, поворачиваясь к своєму дисплею. 


№ этапа Этап Выполнено? 


10. Если время и ресурсы позволяют, повторить этапы 2 — 8, ис- М 
пользуя структурный анализ (например, сложность Маккейба 
(МеСабе сотріехігу) и покрытие кода), чтобы определить об- 
ласти системы, требующие дополнительного тестирования. 
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Построение успешного процесса проектирования 
и разработки системы тестов · 


Полнота — это, конечно, одна часть проблемы. Есть и другие соображе- 
ния по поводу правильного построения системы тестов. В своей основе 
проектирование и разработка тестов — это созидательный инженерный 
процесс, поэтому результаты этого процесса наряду с его атрибутами 
очень важны. Что делает и чего достигает группа тестирования при нали- 
чии успешного процесса? 


Предоставление работоспособных инструментов 
для оценки качества 


Работая над системой тестов, я стремлюсь построить нечто полезное для 
достижения более глобальной цели, которой в данном случае является 
оценка качества системы, предназначенной для тестирования. Что озна- 
чает для системы тестов обладание такими возможностями? 

В первую очередь для меня это означает, что система тестов покрывает 
риски качества системы, как это обсуждалось ранее. Иначе говоря, те раз- 
делы системы, которые с наибольшей вероятностью являются проблемны- 
ми или наиболее важными для заказчиков и пользователей, я должен ис- 
следовать на наличие потенциальных отказов. Определенная степень 
риска всегда присутствует. Таким образом, в процессе анализа рисков каче- 
ства совместно с рабочей группой проекта я оцениваю степени рисков и 
сопоставляю с ними объем тестирования. Система тестов, следовательно, 
должна позволить мне выполнить все необходимые виды тестов в опреде- 
ленном объеме, чтобы надлежащим образом покрыть риски. 

В ходе тестирования мы постоянно ищем равновесие между глубиной 
понимания и широтой покрытия, между определенностью и продвиже- 
нием работ. Стремление к определенности ведет к тому, что тестиров- 
щик создает излишне детализированные, повторяемые тестовые сцена- 
рии, которые затрагивают каждый уголок и каждую частичку свойств, 
функций и поведения системы в рассматриваемой области. Пока тести- 
ровщик направляет все усилия на написание таких тестовых сценариев, 
он не может заняться написанием других тестовых сценариев, покрываю- 
щих другие условия и другие риски качества. Таким образом, при жела- 
нии покрыть еще одно условие и потребности покрыть достаточно хоро- 
шо все ключевые риски качества в рамках выделенных времени 
и бюджета требуется компромиссное решение. 

В процессе анализа рисков в основном примере книги, представлен- 
ном в главе 2, группа проекта “Суматра” присвоила один из четырех уров- 
ней рекомендованных действий большинству рисков качества. 


и Подробное тестирование 

ш Сбалансированное тестирование 
ш Тестирование по возможности 

ш Отчет о наблюдаемых ошибках 
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Различные уровни тестирования — это точки в бесконечном спектре 
вариантов. Тестирование на том конце спектра, где оно осуществляется 
подробно, дает наивысший уровень доверия к оценке качества. Тестиро- 
вание, при котором выдаются отчеты о наблюдаемых ошибках, только 
информирует нас о том, что поведение обычных пользователей системы 
позволяет тестировщику пропустить эту область рисков, если все наблю- 
даемые ошибки обнаружены. 

В моем перечне имеются только четыре из возможных точек. Если 
есть желание, можно сделать более тонкую шкалу. Рекомендуемые дейст- 
вия служат подсказками инженеру-тестировщику. Я предполагаю, что 
инженеры-тестировщики будут использовать профессиональные оценки 
при проектировании и разработке подходящих тестов в рамках имею- 
щихся рекомендаций. 

К различным системам могут применяться различные шкалы рисков. 
Проект “Суматра” готовит пакет обработки текстов для профессиональ- 
ного применения. Таким образом, риски существенны. Влияние сбоев на 
производительность и даже на непрерывное осуществление бизнеса мо- 
жет быть очень серьезным. Системы, предъявляющие повышенные тре- 
бования к безопасности, в частности медицинские программы, средства 
управления производством, военные компьютерные системы, имеют 
шкалу рисков, которая заставляет группы тестирования проводить более 
тщательное и подробное тестирование. Развлекательные системы, на- 
пример компьютерные игры и РУр-плееры, имеют шкалу рисков, кото- 
рая позволяет применить более мягкий подход. Независимо от того, ка- 
кие риски качества есть у системы, предназначенной для тестирования, 
одни риски являются более важными, чем другие. Тестировщикам прихо- 
дится тратить большую часть усилий на проектирование и разработку 
системы тестов, а также на выполнение тестов нацеленных на покрытие 
этих рисков. | 

Покрытие ключевых рисков имеет большое значение, но мы можем 
сделать это таким способом, что тесты не будут иметь отношения к мне- 
нию о системе заказчиков и пользователей. Как-то я работал с группой та- 
лантливых программистов, которая проектировала тест производитель- 
ности для большого сервера под ОМІХ, использовавшегося в системе, 
предназначенной для тестирования. Производительность была действи- 
тельно основным риском качества для той системы. Однако способ, с по- 
мощью которого они спроектировали и реализовали инструменты тести- 
рования, позволял оценивать производительность только при 60%-ной 
загрузке системы. Группа тестирования обнаружила, что при 100%-ной 
загрузке система не просто не справляется с достижением заданных пара- 
метров производительности, а терпит крах. Система тестов, которую 
построили мы как тестировщики, правдиво представляла реальное пове- 
дение пользователей, в то время как система тестов, созданная разработ- 
чиками, этого не делала. 

Эффективная система тестов должна быть высококачественной, 
правдиво отражающей мнение о системе пользователей и заказчиков. 
Процессы выполнения тестов должны способствовать использованию 
системы, предназначенной для тестирования, в манере, аналогичной 
поведению пользователя. Система тестов должна позволять тестиров- 
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щикам оценивать правильность поведения системы при всех последова- 
тельностях действий и пользовательских сценариях с применением 
всех важных наборов данных. Система тестов должна порождать все тес- 
товые условия, необходимые для уравнивания мнения о системе тести- 
ровщиков с мнением пользователей и заказчиков. Это означает также, 
что тестовая среда должна быть похожа на среду заказчика или среду по- 
ставки системы, чтобы можно было обнаружить проблемы, связанные 
со средой, конфигурациями и совместимостью . 


Эффективная реализация, применение, повторное 
использование и сопровождение системы тестов 


Высококачественные системы тестов, ориентированные на критические 
риски качества, будут эффективными, но, честно говоря, я не обладаю 
всеми деньгами и всем временем мира. Это означает, что система тестов 
должна ‘бы столь же эффективной, сколь рациональной. Словарь 
"Метіат-У/ебзіег'з Сойеріаїє Гісіопату" определяет, что “рациональный” 
(еЄбсіепо) означает для объекта, системы или человека быть “продуктив- 
ным с желаемым эффектом... и без потерь”. Другими словами, это опреде- 
ление говорит, что нужно потратить правильное количество времени 
и денег на каждую задачу, необходимую для достижения желаемого эф- 
фекта, в нашем случае — работоспособной системы тестов. Это определе- 
ние имеет множество следствий для системы тестов. 

Устранение ненужных потерь, с одной стороны, означает, что для соз- 
дания системы тестов необходимо использовать минимальное количест- 
во времени и денег. Например, если бы я игнорировал столбец “Рекомен- 
дованные действия” в таблице анализа видов ошибок и их влияния 
и задался целью построить систему тестов, которая обеспечивала бы под- 
робное покрытие всех выявленных рисков, это было бы непродуктивно. 
Покрытие рисков в требуемом объеме, и не более, есть часть эффектив- 
ной работы. 

С другой стороны, не надо тратить деньги на бесполезные элемен- 
ты системы тестов. Приобретение инструментов без предваритель- 
ного проведения анализа затрат и прибыли обычно приводит к фено- 
мену складирования закупленного на полку (5Веёуаге). Некоторые 
компании в буквальном смысле напичканы автоматизированными ин- 
струментами тестирования, закупленными на миллионы долларов и 
сложенными в пыльных углах офисов. Рабское подражание неподхо- 
дящим стандартам документирования может также привести к созда- 
нию огромного числа папок с тестовыми сценариями и процедурами, 
к которым обращались один или два раза, а затем никогда больше не 
открывали. 


ов проектах, в которых поставляются большие и сложные конфигурации или предполага- 
ется, что различные пользователи будут работать с различными конфигурациями среды, 
тест-менеджер, возможно, обнаружит, что перед ним стоит задача, сопоставимая с “мини- 
проектом”, цель которого собрать такую среду в тестовой лаборатории. Как работать в этих 
условиях, описано в главах 6 и 7 моей книги “Маларіпр іће Тезитр Росез5, Зесопа Еайіоті". 
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Необходимо уравновешивать эффективность проектирования и раз- 
работки с эффективностью применения системы тестов. В ранее приве- 
денных примерах я показывал, что незначительное документирование 
тестирования в сочетании с общим низким уровнем квалификации груп- 
пы тестирования приводит к значительным объемам тестирования ай 
Бос, покрывающего вновь и вновь одни и те же риски, тогда как ключевые 
риски качества остаются непокрытыми. Я также видел, что разумное при- 
менение автоматизированных инструментов тестирования приводит со 
временем к значительному повышению эффективности. 

Что касается использования денежных средств, то я считаю полезным 
четко отделять бесполезные расходы и инвестиции. Потратить $1000 на 
инструмент управления дефектами — это, конечно, инвестиция. Первая 
же ошибка, которая не попала в эксплуатационную версию из-за того, что 
использовался хороший инструмент управления дефектами, вероятно, 
покроет все затраты на инструмент. Потратить $5000 на то, чтобы устано- 
вить тестовый сервер в том же офисе, где сотрудники разрабатывают и 
выполняют на нем тесты, а не попытаться использовать такой же сервер, 
находящийся на удалении 500 миль, — также инвестиция. Я наблюдал, что 
потерянное время стоит дороже, чем $5000, уже в случае нескольких не- 
дель проекта тестирования. 

Отфутболивание коленом, жадное “нет” покупке подходящих инстру- 
ментов и среды, расходованию времени на разработку хороших тестовых 
сценариев, реализации процедур, которая требует больше времени, но 
каждый раз дает отличный результат, приводит к болезненной неэффек- 
тивности. Недостаточные, низкокачественные системы тестов облагают 
налогом каждую задачу тестирования, которую выполняете вы и ваша 
группа, налогом в виде потерянного времени. Возможно, это — несколько 
минут здесь, несколько минут там, но иногда это выливается в потерю це- 
лого дня на тестирование. Как гласит пословица: “Сэкономил копейку — 
потратил рубль”. Это еще одна из форм бесполезных расходов, точно та- 
кая же, как покупка инструментов тестирования, которые не будут нико- 
гда применяться. Использование системы тестов обычно включает в себя 
работы по настройке тестового сценария для выполнения и по его демон- 
тажу. Например, вам может потребоваться загрузить большую базу тесто- 
вых данных заказчиков для подготовки к тестированию объема. Иногда 
эти работы можно ускорить за счет использования в нескольких тесто- 
вых сценариях. Это делает тестирование более рациональным, посколь- 
ку время настройки и демонтажа является чисто накладными расходами 
и не оказывает влияния на оценку качества. 

Хотя имеют значение и другие соображения, в целом я предпочитаю, 
чтобы тестовые сценарии и другие активности тестирования выполня- 
лись настолько быстро, насколько это возможно. Таким образом, при 
равном покрытии функциональное тестирование, которое выполняется 
вручную и требует три часа времени, обычно более предпочтительно, 
чем функциональное тестирование, которое выполняется вручную и тре- 


1 
Как разумно применять инструменты автоматизированного тестирования, чтобы полу- 


чить существенный и обоснованный возврат инвестиций в тестирование на основе повы- 
шения эффективности тестирования, можно прочитать в книге Марка Фьюстера (Магк 
Кемутіег) и Дороти Грэм (Догоїу СгаБага) "бо/їшате Тез Ашотанот”. 
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бует четыре часа времени. Даже для автоматизированных тестов ско- 
рость выполнения имеет значение. Я предпочту автоматизированный 
тестовый сценарий, который выполняется в течение обеденного переры- 
ва, сценарию, который запускается на всю ночь. (Конечно, я тоже исполь- 
зую чудесное ночное время, если это возможно, для выполнения автома- 
тизированных тестов, поскольку рациональная система тестов позволяет 
мне выстроить целую последовательность автоматизированных тесто- 
вых сценариев, каждый продолжительностью в один или два часа, в 16-ча- 
совой суперсценарий.) Я смогу быстрее улучшить тест, который выполня- 
ется за один час, чем тест, завершения которого я должен ждать до 
следующего дня. 

Кроме того, я считаю, что должен уравновешивать эффективность на- 
чальной реализации и применения с эффективностью повторного ис- 
пользования, особенно сопровождения. Часто бывает легко соединить 
простой инструмент тестирования и файл тестовых данных. Однако, 
если не продумать заранее, повторное использование этого инструмента 
или файла в других тестах или последующих проектах довольно сложно. 
Я полагаю, что для тех частей системы тестов, которые предполагается 
повторно использовать и сопровождать, требуется значительный объем 
вспомогательных действий и документирования. 

В нашем примере в предыдущей главе диаграмма состояний для функ- 
ционального тестирования, построенная Лин Цу, была одним из инстру- 
ментов, примененным Эммой для проектирования и разработки тестов 
производительности. Лин Цу, вероятно, смогла бы подготовить свои тес- 
ты, мысленно представив переходы состояний и не потратив времени на 
составление диаграммы. Однако создание диаграммы — запись того, что 
ей было известно, для общего пользования — дало возможность повторно 
применить ее. 

Эффективность по важности сопоставима с надежностью. Выполне- 
ние одних и тех же тестов много раз для получения правдоподобных ре- 
зультатов неэффективно. Автоматизированные тесты, которые нельзя 
выполнять без присутствия тестировщика, также неэффективны. Тесно 
связанные тесты, т.е. когда один тестовый сценарий определяет данные 
и начальные состояния для другого сценария, обычно страдают от после- 
довательных сбоев. В этом случае один тест не проходит, в результате сис- 
тема оказывается в неподходящем для выполнения следующих тестов со- 
стоянии. Последующие тесты тоже не проходят, но не потому, что 
система, предназначенная для тестирования, неисправна, а потому, что 
система тестов хрупкая. Все эти ситуации приводят к пустой трате огром- 
ных ресурсов времени на тестирование и анализ и, более того, могут при- 
вести к различным проблемам интерпретации результатов тестирования 
(см. главу 13). 

Два потенциальных источника неэффективности системы тестов 
обусловлены взаимозависимостью тестовых сценариев и общих набо- 
ров данных, которые используются в различных тестовых сценариях. В 
некоторых случаях тестировщики создают тестовые сценарии, которые 
устанавливают предусловия для последующих тестовых сценариев. Это 
означает, что если по какой-либо причине тестовый сценарий не может 
быть выполнен, все последующие тестовые сценарии, зависящие от 
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него, блокируются. Не проблема, если блокирование происходит из-за 
неработающей функциональности. Однако, если это просто вопрос ло- 
гики тестирования, происходят ненужная задержка и ограничение про- 
цесса тестирования. В идеале я бы хотел иметь возможность выбирать 
любой тестовый сценарий и поручать его выполнению любому тести- 
ровщику в любой выбранный день в период выполнения тестов исклю- 
чительно на основе приоритета, доступности тестовой среды и навыков 
тестировщика. Необходимость учитывать, кто и когда выполняет дру- 
гие тестовые сценарии, усложняет этот процесс и часто приводит к не- 
нужным помехам в выполнении запланированных тестов. 

Общие наборы данных порождают аналогичные проблемы. Если один 
тестовый сценарий создает или обновляет данные для других тестовых 
сценариев, это порождает зависимость тестовых сценариев. Если два тес- 
та совместно используют одну и ту же запись или зависимые записи из 
множества таблиц или файлов, то эти два теста не могут быть выполнены 
в одно и то же время. Если эти тесты по случайности выполняются одно- 
временно, это, вероятно, будет воспринято как обнаружение ошибки. 
В результате, в лучшем случае, нужно будет заново выполнить тест, а в худ- 
шем случае будет иметь место неверное толкование ситуации какошибки. 
В первом случае будет израсходовано впустую время группы тестирова- 
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ния. Во втором случае не только время группы тестирования, но также 
время группы разработки и, вероятно, время всей группы проекта будет 
потрачено напрасно, кроме того, будет нанесен удар по доверию группе 
тестирования. 

Наконец, вопросом эффективности является также удобство исполь- 
зования. Система тестов, которую группа тестирования считает удобной 
для применения, — это такая система, которую можно использовать эф- 
фективно и быстро. Чем больше автоматизирована система тестов, тем 
больше она становится похожей на программную систему. Даже ручные 
системы тестов должны проектироваться и разрабатываться так, чтобы 
упростить их применение группой тестирования. 


Выбор подходящих методов 


Эффективность, рациональность, надежность и повторное использова- 
ние будут свойствами системы тестов с большей вероятностью, если мы 
выберем правильные методы. Еще в 1979 г. Гленфорд Майерс в книге “Ис. 
кусство тестирования программ" выделил небольшое количество методов. 
Эти методы используются и по сей день. С тех пор было написано огром- 
ное количество книг и статей, в которых улучшаются методы, определен- 
ные Майерсом, и описываются новые. Разнообразная палитра методов, 
доступных профессионалам, позволяет нам работать более эффективно 
и рационально. В то же время широкий простор для выбора может при- 
вести нас в смущение и до некоторой степени к сектантству. Какой метод 
лучше? Это зависит от обстоятельств. Любой из методов может быть луч- 
шим, но ни один не является таковым. 

Общий принцип состоит в следующем: риски системы качества опре- 
деляют тестовые условия, которые должны разработать тестировщики. 
В свою очередь тестовые условия определяют выбор методов. Помимо 
организационного и технологического контекста, есть два главных сооб- 
ражения. Первое - это уровень автоматизации (если есть) тестирования 
как противопоставление ручному тестированию. Другое соображение от- 
носится ктому, какое проводится тестирование: статическое или динами- 
ческое, структурное или поведенческое, на основе кода, данных или тре- 
бований. 

Автоматизация тестирования обычно выражается в способности 
системы тестов выполняться без участия или при частичном участии че- 
ловека. Его действия могут заключаться в работе с системой, предназна- 
ченной для тестирования, в загрузке данных для нее и в сравнении полу- 
ченного результата с ожидаемым. Это может быть сделано с помощью 
инструментов, как доступных на рынке, так и разработанных на заказ. 
Автоматизация тестирования, вероятно, может позволить (и некото- 
рые производители коммерческих инструментов тестирования утвер- 
ждают, что позволяет) тестировщику спроектировать и разработать 
полный комплект тестовых сценариев, а затем с небольшими затратами 
или вовсе без них бесконечно повторять тестовые сценарии. Те, кто пы- 
тался это сделать, говорят, что этот план не всегда срабатывает. 

Некоторые виды тестов хорошо подходят для автоматизации. Напри- 
мер, я использую инструменты автоматизированного тестирования для 
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большей части тестирования производительности и надежности. Функ- 
циональное регрессионное тестирование стабильной системы также хо- 
рошо подходит для автоматизации. 

Однако некоторые виды тестов совсем не приспособлены к автома- 
тизации. Например, в большинстве случаев тестирование обработки 
ошибок состоит в умышленном создании условий отказов сети, диско- 
водов и подачи электроэнергии. Для человека не составит труда отклю- 
чить кабель, дисковод или сетевую вилку, но машина этого сделать не 
может. 

Один из моих клиентов попытался автоматизировать конфигурацион- 
ное тестирование и обнаружил, что большая часть работы состоит в изме- 
нении операционной системы и приложений, установленных в тестовой 
среде. Автоматизация 10 — 25% работы, которая заключается в проверке 
системы после конфигурирования, не имеет большого смысла, особенно 
с учетом того, что работа разбита на части продолжительностью по часу, 
которые перемежаются часами работы вручную для комплекта тестов, 
выполняемого в течение недели. 

Даже если автоматизация действительно имеет смысл, это по- 
прежнему остается большим и рискованным мероприятием. Затраты, не- 
обходимые для автоматизации тестов, не равны затратам на написание 
тестовых скриптов, выполняемых вручную. Мой опыт показывает, что 
для создания автоматизированных тестов, удобных для сопровождения, 
должна быть выстроена целая инфраструктура, позволяющая тестиров- 
щику впоследствии определить действия, данные и ожидаемые результа- 
ты в некотором формате, отличном от программы. Простая запись дейст- 
вий, входных и выходных данных, а затем их воспроизведение не 
срабатывают в долгосрочной перспективе, за исключением особых об- 
стоятельств, когда пользовательский интерфейс действительно не изме- 
няется, а изменения касаются только бизнес-логики программы, не затра- 
гивающей интерфейс. 

Помимо затрат на создание тестовой инфраструктуры, часто серьез- 
ные вложения приходится делать в сами инструменты, которые могут 
стоить сотни тысяч долларов. Наконец, автоматизация тестирования 
предполагает внесение изменений в процесс тестирования и наличие 
других навыков, необходимых группе тестирования, причем все это 
должны быть управляемо. Поскольку существует много вариантов, при 
которых эта затея может пойти в неверном направлении, ходят ужасные 
рассказы о провалившихся проектах автоматизации тестирования. Один 
из моих клиентов никогда не произнесет в разговоре словосочетание “ав- 
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томатизация тестирования”, поскольку однажды уже потратил сотни ты- 
сяч долларов на работы, которые не дали никакого результата. Инстру- 
мент лежит на полке без движения, скрипты, не приспособленные 
к сопровождению, удалены. 

Тестирование не должно быть ручным или автоматизированным, оно 
может быть ручным и автоматизированным. Тесты, удобные для автомати- 
зации, могут и во многих случаях должны быть автоматизированы, а мето- 
ды ручного тестирования должны применяться ко всем другим тестам. 
В некоторых случаях единственный тестовый сценарий может быть и руч- 
ным, и автоматизированным. Функциональное тестирование Интернет- 
приложения, в котором я участвовал, включало в себя генератор загрузки 
для моделирования 50 000 пользователей, который работал в то время, ко- 
гда мы выполняли функциональные тесты, чтобы посмотреть, как система 
будет реагировать на запросы и вести себя под нагрузкой. 

В разговорах с опытными тестировщиками можно обнаружить широ- 
кое разнообразие мнений о правильном использовании автоматизации 
тестирования и окупаемости вложений в нее. Некоторые, особенно про- 
изводители инструментов, склонны к излишнему энтузиазму относитель- 
но выгоды применения таких инструментов. Другие демонстрируют бо- 
лее прагматичные и даже скептические точки зрения. 

Тесты, независимо от того, являются они ручными или автоматизиро- 
ванными, могут быть статическими или динамическими. Статический 
тест не приводит к выполнению исходного кода программы. Например, 
некоторые классифицируют рецензирование кода как статическое тести- 
рование вручную. Анализ сложности кода, программы анализа стиля 
кода, например ШивСиС++, и даже компиляторы могут рассматриваться 
как автоматизированные статические тесты. Динамическое тестирова- 
ние — это то, что представляют себе большинство людей, когда они гово- 
рят о тестировании. Это реальное выполнение некоторой части или все- 
го кода системы, предназначенной для тестирования, и сравнение 
ожидаемых результатов с реальными. 

Динамические тесты могут быть ориентированы на разные уровни 
системы, обычно их называют структурными и поведенческими (см. 
главу 1). Структурные тесты ищут ошибки на основе внутреннего уст- 
ройства программы, а поведенческие тесты ищут ошибки на основе по- 
ведения системы, которое имеет внешние проявления. Более ранние 
фазы тестирования обычно больше ориентируются на структурные 
тесты, а более поздние, как правило, ориентируются на поведенческие 
тесты. 


Варианты точек зрения приведены в книгах Канера (Капег), Баха ( Васі) и Петтикорда 
(Рецісрога) “Г.е550т5 Геатпе4 іп Зойшате Тейт”, Фьюстера (Еемѕгег) и Грэм (СгаБапа) "5о/їшате 
Тезі Ашотаййот", Дастин и др. “Автоматизированное тестирование программного обеспечения", на 
персональной страничке Канера муги .Капег.сот в разделе “Агсһігесіцгеѕ ої Те5і Ашотайоп” 
и в статье Баха "Тез Ашотайоп Зпаке-оЙ” на мугу.заціяйсе.сот. Обсуждая автоматизацию 
тестирования и тенденцию некоторых людей переоценивать возможности инструментов 
автоматизации, Канер писал мне: “Есть серьезная польза от применения многих инструмен- 
тов тестирования, но эти продукты так активно рекламируются, а советы некоторых горя- 
чих сторонников столь ужасны, что на практике эти инструменты и их продавцы и консуль- 
танты часто приносят больше вреда, чем пользы”. 
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Однако методы и инструменты структурного тестирования находят 
свое место и в системном тестировании. Генераторы загрузки для 
Интернет-приложения, о которых я упоминал выше, были получены из 
драйверов для структурных тестов, созданных программистами в ходе 
модульного тестирования для проверки основных программных интер- 
фейсов в функциональности сервера. Это также один из примеров по- 
вторного использования средств тестирования. 

Обычно я не выбираю какой-то один метод тестирования. Я рассмат- 
риваю каждое из условий, которые хочу выстроить в системе, предназна- 
ченной для тестирования, и выбираю наиболее подходящий метод для 
этого условия. В основном примере книги Эмма применяла разные мето- 
ды для тестирования нагрузки, мощности и объема. Это можно сравнить 
с тем, что художник не выбирает наилучший цвет для создания картины, 
он использует целую палитру цветов, не задумываясь, смешивает их и ме- 
няет по ходу работы над картиной. 


Предотвращение дефектов 


В главе 2 отмечалось, что анализ рисков качества позволяет не только 
принять решение по поводу того, где искать ошибки. Он также может 
создать условия для того, чтобы избежать ошибок. Хороший процесс 
проектирования и разработки системы тестов может сделать то же са- 
мое. В основном примере Эмма обнаружила, что для диалогового окна 
открытия документа не задано, сколько файлов оно может показывать. 
Это могло бы выразиться в ошибке надежности, если бы программист 
не вставил проверки, что список слишком велик, поскольку переполне- 
ние могло бы вызвать крах системы. Либо могла возникнуть ошибка 
функциональности, если бы программист вставил проверку ограниче- 
ния по своему усмотрению, но пользователи сочли бы его недостаточно 
большим. 

Так часто бывает. Проектирование и разработка тестов заранее, до за- 
вершения программирования, позволяет вступить в дискуссию с про- 
граммистами о том, как система должна работать. В этот диалог включа- 
ются системные проектировщики и программисты, пользователи 
ианалитики, атакже все другие заинтересованные лица проекта. По мере 
создания системы тестов, я могу обсудить с заинтересованными лицами 
вопрос о том, что я собираюсь тестировать и какие результаты ожидаю 
получить. Довольно часто я получаю такие ответы: “Знаете, мы не думали 
о такой возможности”. Каждый из таких ответов — это, по крайней мере, 
одна предотвращенная ошибка". 


В книге Гетцеля (Нее!) “ Сотрігіє Сиійе іо 5о/їшате Тезіїпр" обсуждается статическое тести- 
рование, направленное на предотвращение дефектов. Борис Бейзер в “бойшате Теѕйпр 
Тесітідиєї" пишет, касаясь раннего начала тестирования в проекте, что иногда “угрозы тес- 
тирования” достаточно для предотвращения ошибок, поскольку программист, зная, что вы 
будете выполнять тот или иной тест, пишет программу так, чтобы не допускать в ней оши- 
бок, которые этот тест может обнаружить. Другие отмечают, что все, что происходит до 
компиляции, является контролем качества, а не тестированием. Например, посмотрите 
книгу Уотса Хемфри (Майѕ Нитрігеу) “Гофисйот іо ве Ретзопа! 5о/їшате Ртосез5". 
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Решение проблем 


При проектировании и разработке хорошей системы тестов возникает 
много проблем, часть которых связана с технологиями и методами. Тес- 
ты для системы на меб-основе отличаются от тестов для системы, предна- 
значенной для универсальной машины. Автоматизированные и ручные, 
структурные и поведенческие тесты требуют разных подходов. Однако 
есть ряд общих проблем, которые заслуживают упоминания. 


Сколько условий в тестовом сценарии? 


Соображения эффективности и производительности, о которых говори- 
лось выше, могут создать представление, что большие тестовые сценарии 
лучше, чем маленькие. (Слово “большие” я употребляю, имея в виду созда- 
ние и оценку большого числа тестовых условий.) Если тестовые условия 
вытекают из рисков качества, то как только мы покрыли все тестовые 
условия, мы обеспечили должное управление рисками, для чего нас, соб- 
ственно, и нанимали на работу. Тестировщики создают тестовые усло- 
вия, выполняя тестовые сценарии. Подробности этого процесса рассмат- 
риваются в главе 13. Таким образом, основной единицей работы по 
выполнению тестов является тестовый сценарий. Таким образом, может 
показаться, что повышение эффективности работы связано с тем, что ка- 
ждым тестовым сценарием надо постараться покрыть максимально воз- 
можное количество тестовых условий. Однако сочетание большого числа 
условий в одном тестовом сценарии может привести к повышению числа 
неудачных завершений теста. 

Во-первых, вы можете наткнуться на несколько ошибок на одном шаге 
тестового сценария, что не позволит определить, какое изменение в со- 
стоянии системы привело к сбою. Во-вторых, один из сбоев может быть 
настолько исключительным по эффекту, что может скрыть другие, менее 
очевидные (но, возможно, столь же важные) сбои, а это приведет к про- 
пуску дефекта в следующем тестовом цикле или попаданию его в зксплуа- 
тационную версию. В-третьих, можно получить отказ, который заведет 
тестирование в тупик и не позволит проверить условия, которые могли 
бы открыть последующие отказы, подчас не менее важные. В-четвертых, 
тестовый сценарий со многими условиями с большей вероятностью за- 
вершится неуспешно в отличие от сценария с меньшим числом условий, 
если в остальном они похожи. В результате отчет о ходе выполнения тес- 
тов, представленный в виде информации об успешно и неуспешно завер- 
шенных тестах, по всей вероятности, создаст пессимистическую карти- 
ну, которая может повредить доверию группе тестирования. 

Однако существует несколько исключений. Например, тесты, кото- 
рые часто называют приемочными, проектируются для того, чтобы проде- 
монстрировать стабильность системы и соответствие требованиям. 
В первом случае это делается для поставки версии заказчику, во втором — 
группе тестирования. Ожидается, что эти тесты пройдут без ошибок. Лю- 
бые отказы означают, что необходимо вернуть систему передающей орга- 
низации для дальнейшей работы. Основная цель — завершить эти тесты 
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как можно быстрее, поэтому наличие большого числа условий в одном 
тесте — отличная идея. 

Еще один пример. Не удается создать некоторое число интересных 
условий в одном тестовом сценарии, потому что набор действий, необхо- 
димых для получения целевого тестового условия требует прохождения 
управляющей логики, которая направляет вас через ряд других тестовых 
условий. Возвращаясь к основному примеру, заметим, что тестирование 
рисков качества, относящихся к эффективности миграции файлов (см. 
2.008 и 2.009 в таблице анализа видов ошибок и их влияния), обязательно 
покроет риски, связанные с тем, работает ли вообще миграция файлов 
{риски 2.010 и 2.011). 

Этот пример также описывает другую ситуацию, при которой покры- 
тие нескольких условий неизбежно, когда одно и более действий связаны 
с интересующими нас тестовыми условиями, которые устанавливают зна- 
чения данных или внутреннее состояние, необходимое для оценки целе- 
вого условия. Приведем более понятный пример. Предположим, что вы 
тестируете базу данных на обновление записи. В некоторых случаях, как 
в примере с базой данных, вы можете создать тестовые условия, которые 
вы не вычисляете явно, но можете сделать вывод об их состоянии. Пусть 
вы добавили запись, проверили, что счетчик записей увеличился на еди- 
ницу, удалили запись, проверили, что счетчик уменьшился на единицу, 
а затем подтвердили, что добавленная запись отсутствует в базе. Вы може- 
те сделать вывод, что добавление записей работает верно, хотя все, что 
вы реально проверили, это общее число записей и условие удаления. 


Перетестирование сторонних компонентов 


Другой проблемой, которая становится все более традиционной для тес- 
тирования, является интеграция сторонних компонентов в систему, ко- 
торая подвергается тестированию. Здесь я имею в виду, что одна группа 
разрабатывает систему (группа разработки) для второй группы (пользо- 
вателей и заказчиков). Система включает в себя фрагменты, предостав- 
ленные группе разработки третьей стороной (производителями, постав- 
щиками или партнером по аутсорсингу). 
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Ситуация может быть еще более сложной из-за наличия большего чис- 
ла сторон, т.е. нескольких внешних групп, поставляющих части системы. 
Сторонние компоненты могут быть разработаны на заказ или представ- 
лять собой часть коммерческого пакета. Проблемы, которые здесь возни- 
кают, бывают и политическими, и техническими. 

С технической точки зрения, здесь есть две фундаментальные пробле- 
мы тестирования. Во-первых, тестирование, выполненное третьей сто- 
роной, может не соответствовать вашей оценке и расстановке приорите- 
тов рисков качества системы. Во-вторых, тестирование, выполненное 
третьей стороной, вероятно, не предполагало тестирование компонен- 
та, интегрированного в вашу систему, поскольку группа тестирования 
третьей стороны независимо от квалификации может не прочувствовать, 
каким будет мнение о системе ваших заказчиков и пользователей. Вы мо- 
жете преодолеть эти проблемы, изучив тестирование, проведенное по- 
ставщиками и заполнив пропуски в вашем собственном тестировании. 
Однако часто бывает полезно объединить усилия групп, направленные 
на тестирование компонента. 

Политические проблемы, связанные с любым из подходов, имеют 
большое значение. Поставщик компонента может отказаться афиширо- 
вать результаты тестирования и предоставлять вам систему тестов. Такая 
информация о тестировании может содержать нелестные отзывы о каче- 
стве компонента, который они продают вам, или о беспорядке, который 
выдается за процесс разработки в компании поставщика. Даже когда ре- 
зультаты тестирования хорошие, а процесс поставлен отменно, постав- 
щик на законном основании может не доверять пользователю, которому 
эта информация могла бы быть предоставлена. В частности, я сталкивал- 
ся с ситуациями, когда менеджеры проектов пытались использовать ре- 
зультаты тестирования для обсуждения скидок после состоявшейся про- 
дажи и даже для отмены контракта. 

Я также встречался с хитростями, которыми пользуются поставщики 
при общении с заказчиками. Один из моих клиентов был приглашен на 
прогулку поставщиком программных решений. Поставщик продавал ему 
большую серверную программу, про которую утверждалось, что она была 
тщательно протестирована. Я сказал: “Отлично, предоставьте нам резуль- 
таты тестирования и инструменты тестирования”. Поставщик отказался, 
утверждая, что они являются конфиденциальными. Будучи довольно ци- 
ничным, я немедленно предположил, что результаты тестирования пока- 
зывают, что программа полна известных ошибок и, вероятно, протести- 
рована неадекватно. 

Они действительно пообещали предоставить инструмент, но потом 
взяли свои слова обратно. Оказалось, что инструмент был столь ужасным 
и столь слабо документированным, что никто, кроме одного инженера- 
тестировщика, не мог с ним работать. Затем они осмелились выставить 
дополнительный счет моему клиенту более чем на $2000 в день плюс на- 
кладные расходы за этого инженера-тестировщика, который потратил 
две недели, показывая, как использовать инструмент. Мой цинизм был 


1 см. некоторые идеи по этому поводу в главе 10 книги “Мапартр ійе Теѕііпо Руосе55, ‘бесота 
Еайіоп". 
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позже вознагражден, когда, как я и подозревал, тестирование обнаружи- 
ло массу проблем в их программе, которыеони должны были исправить. 
Какой бы подход вы ни выбрали, советую четко зафиксировать реше- 
ние этого вопроса до того, как подписан контракт и завершена работа над 
планом проекта. Ваши поставщики и другие представители третьей сто- 
роны будут вести себя более гибко и помогать ориентироваться в их слож- 
ном и опасном мире, если об этом договориться заранее. Кроме того, 
ваши менеджеры проекта должны знать заранее, что наличие сторонних 
компонентов означает дополнительное тестирование. Многие менедже- 
ры проектов ошибочно полагают, что раз поставщик тестировал свои 
компоненты или утверждает, что он это делал, не требуется никакого до- 
полнительного тестирования при интеграции компонента в систему. 


Неясно сформулированные требования, профили 
пользователей и описания конфигураций среды 


Я сделал акцент на значении высококачественной системы тестов, кото- 
рая правдиво воспроизводит опыт качества пользователей и заказчика. 
Это предполагает, что я смогу понять, как и в каких средах будет приме- 
няться система. Иногда эта часть информации не предоставляется группе 
тестирования. 

В некоторых случаях это просто проблема процесса описания тре- 
бований, который либо слаб, либо отсутствует. Например, в одном из 
проектов моя группа получила документ с требованиями для сложной 
системы, который состоял из одной странички, а сами требования 
формулировались примерно так: “Пользователю предоставляется воз- 
можность работы с электронной почтой”, “Электронная почта пользо- 
вателя будет поддерживать вложения” и “Браузер будет обеспечивать 
доступ к популярным међ-сайтам”. Мы начали задавать вопросы: “Ка- 
кая кодировка электронной почты поддерживается?”, “Какие конкрет- 
но допускаются виды вложений в почту?”, “Насколько большими по 
размеру могут быть вложения?”, “Что произойдет, если “популярные” 
мер-сайты содержат элементы АсНуеХ, соо 4е$ и т.д.?” Этим мы заста- 
вили проектную группу рассмотреть вопросы, которые, если их не ре- 
шить, превратятся в дефекты. Но это потребовало 20—30% дополни- 
тельных расходов на разработку тестов . 

Иногда процесс сбора требований недостаточно детализирован, по- 
этому трудно точно определить, что требуется. Мои коллеги и я создали 
инструмент тестирования для клиента, который был в середине процесса 
реинжиниринга системы. Было трудно предсказать заранее, какие функ- 
ции должен иметь инструмент и в какой среде он будет работать. В резуль- 
тате мы применили спиральный жизненный цикл разработки системы, 
создавали и поставляли прототип каждые три-четыре недели и спрашива- 
ли пользователей (в данном случае, группу тестирования клиента): “Это 
то, что вам нужно?” Обычно мы получали ответы следующего содержа- 
ния: “Да, но нам нужно уметь делать также это и это”. 


Мне нравится книга Карла Вигерса (Кагі Міевегѕ) “бойшате Кедитетет5” за рассмотрение 
хороших требований и за грамотно выстроенные процессы их сбора. 
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У меня накоплен большой опыт работы в ситуациях, когда по разным 
причинам требования определены нечетко. Мои тестировщики обнаружи- 
ли, что в таких ситуациях можно эффективно работать за счет увеличения 
взаимодействия с проектной командой. Мы задаем большое количество во- 
просов о том, как система должна работать, что пользователи будут с ней 
делать, в каких средах она будет работать. Также помогут прототипы, 
имитации и модели. Сотрудники технической поддержки, систем сетевой 
поддержки, аналитики и пользователи текущих версий системы могут рас- 
сказать, что пользователи делают с системой в большинстве случаев. Спе- 
циалисты по продажам, маркетингу, бизнес-аналитики расскажут об ожи- 
даниях от новой системы. 

Я также считаю, что в группу тестирования должны входить сотрудни- 
ки с более высоким уровнем знания предметной области, если требова- 
ния, применение системы и эксплуатационные конфигурации среды сла- 
бо определены или это трудно сделать. Если группа тестирования не 
располагает точным определением ожиданий пользователей о поведе- 
нии системы при конкретных условиях тестирования, мне нужно, чтобы 
это определение могла дать сама группа. 

Одно изэмпирических правил, которое я применяю в проектах с неяс- 
но определенными требованиями, заключается в следующем: “Есть со- 
мнения — пиши отчето дефекте”. Это означает информирование о дефек- 
те всякий раз, когда невозможно с основанием утверждать, прошел тест 
без ошибки или нет. Это приводит к тому, что проектная группа, исполь- 
зующая процессы управления дефектами и управления изменениями (см. 
главы 14 и 16), исследует непонятное поведение системы. Поскольку это 
происходит чаще всего в процессе выполнения тестов, а не в процессе их 
разработки, необходимо документировать тестовые сценарии с доста- 
точной степенью неоднозначности. 


Уравновешивание покрытия, сроков и бюджета 


Процесс, представленный в этой и предыдущей главах, страдает от свой- 
ственного ему риска размывания границ. Следуя ему буквально, группа 
тестирования разрабатывает тесты в порядке приоритета, а это означа- 
ет, что полное покрытие для элементов с высоким приоритетом появля- 
ется раньше, чем хоть какое-то покрытие будет создано для элементов 
с низким приоритетом. Это нормально, если у вас достаточно времени 
и есть дополнительное время на разработку всех тестов, которые были за- 
фиксированы в период планирования. Но что если вы вышли за времен- 
ные рамки? 

Независимо от тщательности выполнения оценки затрат иногда я де- 
лаю в ней ошибки. Я обнаружил, что наиболее часто занижаю оценки для 
задач, которые связаны с разработкой инструментов и автоматизирован- 
ных тестов. Поэтому я тщательно отслеживаю ход работ относительно 
графика, по крайней мере, еженедельно. Если задача выходит за рамки 


Дополнительные идеи по этому вопросу можно найти в статье Джоанны Ротман “Теѕііпр 
іп ре Дагі" в журнале "5о/їшате ТезйптЕ апа Оиаійу Епріпеєтіто", Уоате 1, Іѕѕџе 2 (Маг/Арг 
1999), которая доступна в настоящее время на мму/ тофтап.сот и уум.5іскутіпаѕ.сот. 
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сроков, я должен быстро понять, как скажется эта задержка на вьшолне- 
нии тестов. Нежелательно и часто политически недальновидно задержи- 
вать начало тестирования компонента, сборки или полной системы толь- 
ко из-за того, что средства тестирования, процесс выполнения тестов 
или тестовая среда не готовы. 

Я полагаю, что должен быть честным перед самим собой в таких ситуа- 
циях. Я бы предпочел не использовать в этом случае план на случай непред- 
виденных обстоятельств. Все-таки сначала я попытаюсь следовать части 
моего основного плана, а не плана на случай непредвиденных обстоя- 
тельств. Однако мои предпочтения не всегда способны управлять реаль- 
ной ситуацией. Поэтому я должен четко представлять, что происходит.. 
Если какой-либо элемент проекта не находится под контролем, наступает 
время, когда я должен пересмотреть старый подход и выбрать новый. 

Навязанные извне изменения плана или доступности ресурсов также 
могут повлиять на возможности выполнения всех запланированных тес- 
тов. Я обнаружил, что могу свести к минимуму влияние этих ситуаций, 
если разрабатываю тесты небольшими частями. Другими словами, разра- 
ботка тестов должна обеспечивать для начала некоторый уровень тести- 
рования и достаточно часто добавлять дополнительные инкременты сис- 
темы тестов, а не вестись по принципу: все или ничего. Спиральный 
и итерационный жизненный цикл по этой причине наиболее удачно под- 
ходит для разработки системы тестов, особенно для инструментов тести- 
рования и автоматизированных тестов. : 

В некоторых случаях вы, вероятно, обнаружите, что нужно вновь рас- 
смотреть соотношение между подробным и широким покрытием. Выше 
говорилось о шкале: подробное тестирование - сбалансированное тести- 
рование — тестирование по возможности — отчетность о наблюдаемых 
дефектах. Подробное тестирование обычно стремится аккумулировать 
непропорционально большой объем всего тестирования, включая разра- 
ботку системы тестов. 

Итак, имеет смысл для начала разработать сбалансированные тесты для 
этих рисков качества системы, а затем вернуться и улучшить полученный 
набор тестов, как только будет заверщена разработка остальной части тес- 
тового покрытия. Если сначала сосредоточиться на разработке подробных 
тестов для наиболее критических рисков качества и проигнорировать рис- 
ки более низких приоритетов, можно исчерпать время, отведенное на раз- 
работку тестов, раньше, чем удастся приступить к рискам низшего приори- 
тета. Это означает, что у вас будет много тестов, покрывающих очень 
небольшое множество рисков системы качества, и совсем не будет тестов 
для проверки других областей. Это, пожалуй, не то, что нужно. Честное об- 
суждение и корректировка курса совместно с руководством и другими за- 
интересованными в тестировании лицами в случае, если разработка тес- 
тов выходит за рамки сроков, — наилучший способ провести переоценку 
соглашений и пересмотреть решения, принятые ранее. 


Внедрение усовершенствований 


Как улучшить разработку системы тестов? Многие ответы на этот вопрос 
включают в себя овладение новыми методами и технологиями. Это, безус- 
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ловно, важно, но зависит от конкретной ситуации и поэтому не обсужда- 
ется в моей книге. Однако есть несколько общих соображений, касаю- 
щихся самого процесса, которые я могу предложить для рассмотрения. 


1. 


Оцените качество существующей системы тестов. Отлично, если вы 
начинаете с нуля. Вы можете построить совершенную систему тестов 
с самого начала. Однако если у вас уже есть система тестов, спросите 
себя, хороша ли она. Если вы ответите “нет”, можно ли изменить про- 
цесс и внедрить усовершенствования, которые позволят повысить ка- 
чество тестирования, какой бы проект ни осуществлялся? Конечно, 
если вы увеличите тестовое покрытие в середине проекта, вам могут 
предъявить претензии, что вы необъективно завышаете планку каче- 
ства. Очень важно получить одобрение со стороны заинтересован- 
ных лиц. Но я бы поддержал вас, если вы не игнорируете задачу при 
условии, что она политически неприятна. Когда я поступал таким об- 
разом, то несколько раз сталкивался с тем, что люди говорили: “Мы не 
хотим повышать планку качества в середине проекта”, но в то же вре- 
мя они не были преисполнены оптимизма относительно связанных с 
этим пропусков в тестовом покрытии. 


Изучайте и применяйте достижения в технологиях тестирования. 
Часть процесса, который я предложил в этой главе, включает в себя 
выбор подходящих методов тестирования. С развитием инструмен- 
тов тестирования, быстрой эволюцией технологий системной разра- 
ботки и развитием новых идей тестировщиками-профессионалами 
методы тестирования, подходящие для решения определенных задач 
тестирования, постоянно меняются. Эти изменения не означают, что 
старые методы больше не подходят. Они означают, что доступны но- 
вые, более прогрессивные методы. Можно привести подходящую ана- 
логию из медицины. Врачи обязаны проходить непрерывное обуче- 
ние для сохранения своих лицензий, чтобы они могли применять 
последние достижения в области охраны здоровья и лечения заболе- 
ваний пациентов. Область тестирования программ развивается не ме- 
нее быстро, поэтому мы должны изучать новые достижения, чтобы не 
сомневаться, что мы проводим тестирование настолько эффективно 
и рационально, насколько это возможно. 


3. Примите долгосрочный план. Все эти рекомендации работают луч- 


ше, если реализуются в течение продолжительного времени. Сис- 
темы тестов аналогично системам, которые мы тестируем, обычно 
достаточно инерционны. Способ движения вперед состоит в том, 
чтобы следить за возможностью сделать процесс разработки тес- 
тов лучше, особое внимание следует обращать на выявление того, 
как слабости в системе тестов, существующие сейчас, влияют на 
возможность проведения качественного тестирования, а затем от- 
вечать на эти вызовы с помощью долгосрочного плана усовершен- 
ствований. Этот долгосрочный план должен также учитывать, что, 
поскольку вы пытаетесь улучшить систему тестов, должен разви- 
ваться и контекст тестирования. Любой долгосрочный план улуч- 
шения системы тестов и процесса ее разработки должен быть наце- 
лен в будущее. Какими свойствами и каким поведением будет 
обладать система? Какие планируются изменения в компании? Ка- 
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кие существуют возможности для изменений, например желание 
руководства что-то усовершенствовать, и как их можно усилить? 


4. Одобрите подходящую документацию. Существует множество шаб- 
лонов для документирования системы тестов. Но простое заполне- 
ние пропущенных мест в шаблонах не обязательно приведет к полу- 
чению подходящей документации. Если у вас есть существующая 
система тестов, вы можете обнаружить, что стиль ранее сделанной 
документации слишком точен. В этом случае перевод документа- 
ции к новому, одобренному стилю может быть началом вашей но- 
вой работы, которая должна быть со временем завершена. В случае 
слишком подробного документирования, вероятно, вам захочется, 
чтобы устаревшая документация постепенно была заменена доку- 
ментацией, оформленной в новом стиле. В любом случае маловеро- 
ятно, что у вас окажется достаточно времени и средств, чтобы вы- 
полнить основные изменения стиля в один присест для большой 
системы тестов, поэтому постепенное изменение может стать наи- 
лучшим способом решения проблемы. 


5. Оцените и согласуйте навыки тестировщиков. Это оказывает боль- 
шое влияние на проведение тестирования. Это значит, что вам нуж- 
но выстроить группу тестирования вплоть до приема новых сотруд- 
ников на работу. По мере формирования вашего долгосрочного 
плана вам необходимо проверять перечень критических навыков, 
который вы составили ранее. Какие новые навыки неявно вытека- 
ют из изменений, которые вы намереваетесь сделать в системе тес- 
тов и процессе ее разработки? Вам потребуется план, для того что- 
бы группу тестирования подтянуть до предлагаемого уровня 
процесса тестирования. И в принципе, что хорошего в идеальном 
плане и в идеальном процессе, если у вас нет квалифицированной 
команды для их проведения в жизнь? 


Как показывает мой опыт, в проектах, где мы использовали существую- 
щую систему тестов, наиболее простым подходом было постепенное усовер- 
шенствование. Начало с нуля приводит к другой совокупности проблем. 

Итак, мы завершили подготовительную часть процесса тестирования. 
Мы подготовились к выполнению тестов, чтобы выяснить качество сис- 
темы, предназначенной для тестирования. Пора перейти к этому. 


№ этапа Этап Выполнено? 
2. Подготовка: собрать людей и подготовить тесты. м 
2.А. Посредством найма и обучения создать команду 


специалистов-тестировщиков, обладающих соответствующи- 
ми умениями, навыками, отношением к делу и мотивацией. 


2.В Спроектировать, разработать, получить и верифицировать 
систему тестов, которую группа тестирования будет использо- 
вать для оценки качества системы, предназначенной для тес- 
тирования. 


Проведение 


ы достигли момента основного логического перехода в процессе 
тестирования. Джамал и его группа завершили важную часть про- 
цесса тестирования. До сих пор описывалась подготовка к тестированию. 
Теперь обратим наше внимание на проведение тестирования. 
Проведение тестирования — более понятная часть, чем планирование 
тестирования и подготовка к нему, но и эту фазу тестирования не всегда 
понимают правильно. Неверное определение цели, часто сопровождае- 
мое стремлением “убедиться в том, что система работает», может поро- 
дить новые проблемы. Если это происходит внутри группы, то при обна- 
ружении ошибок могут иметь место недовольство и превышение сроков. 
Если это происходит вне группы тестирования, то при информировании 
о результатах тестирования могут возникать конфликты и неприятные 
неожиданности. Когда проектная группа, которая не смогла предвидеть 
необходимости изменений, должна принять решения в связи с плохими 
результатами тестирования, может возникнуть хаос. 


№ этапа Этап Вьшолнено? 
3. Проведение: выполнение тестов и сбор результатов. О 
З.А Получение и установка тестовой версии, состоящей из всех О 
или нескольких компонентов системы, предназначенной для 
тестирования. 
3.В Назначение ответственных за выполнение комплекта тестов О 


на каждой из тестовых версий, его отслеживание и управле 
ние им. 


ГЛАВА 12 


Передача материалов: 
управление тестовыми версиями 


аже когда люди понимают необходимость передачи тестовой вер- 

сии группе тестирования, лишь немногие осознают сложность это- 
го процесса и проблемы, связанные с ним. Управление тестовой версией 
является завершающим этапом управления конфигурацией системы, кон- 
троля изменений, сборки системы и поддержки системной библиотеки. 
Как и тестирование, эти действия могут оказать очень большое влияние 
на проект, как положительное, так и отрицательное. 

Чтобы получить при тестировании точную и имеющую смысл оценку 
качества, управление тестовыми версиями и все предыдущие этапы долж- 
ны выполняться очень точно и быстро. Представьте испытание лекарст- 
ва, когда все или некоторые дозы лекарства, принятые пациентами, были 
фальсифицированы путем добавления токсинов или ослаблены при по- 
мощи инертных материалов. С каким доверием вы отнесетесь к результа- 
там испытаний безопасности и действенности лекарства? Аналогично, 
если невозможно установить с точностью до каждого составляющего мо- 
дуля состав системы, тестируемой в каждом цикле, что мы сможем сказать 
о качестве этой системы? 

Поэтому, чтобы процесс управления тестовыми версиями был работо- 
способным, мы должны начать с известных компонентов, которые из- 
вестным образом отличаются от компонентов, исследованных на преды- 
дущих циклах. Мы должны собрать эти компоненты в тестопригодную 
версию сучетом определенного уровня полноты (который соответствует 
фазе тестирования). Мы должны передать, установить и настроить эту 
версию в тестовой среде. Только после этого мы можем приступить к 
оценке качества. 

Без программы, предназначенной для тестирования, не бывает тести- 
рования. Каким бы очевидным ни было это утверждение, многие компа- 
нии, разрабатывающие программное обеспечение, очень слабо поддер- 
живают процессы управления тестовыми версиями. Часто бывает, что 
ответственность за сборку тестовой версии передается отделу тестирова- 
ния, который плохо подготовлен к выполнению этих задач. В таких случа- 
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ях эти процессы определяются как ответ на возникающие проблемы. Мы 
же рассмотрим, как управлять этими процессами при помощи тщательно- 
го планирования, до начала сборки и рационально . 


Процесс сборки тестовых версий 


Процесс 8 — это реальный процесс сборки тестовых версий. Этого про- 
цесса будет вполне достаточно для продукта, который является прило- 
жением для ПК, системой на основе браузера, размещенной на сервере 
приложений, или простой клиент-серверной системой. Сложности, воз- 
никающие с разделяемыми (совместно используемыми) базами данных, 
заказным аппаратным обеспечением, и другие проблемы будут рассмот- 
рены в конце главы. 


Процесс 8. Процесс сборки тестовой версии 


№ этапа Этап Выполнено? 


1. Отобрать содержимое для конкретной тестовой версии (ис- о 
правления ошибок, новые свойства и документацию). 


2. Реализовать изменения, необходимые для исправления де- 0 
фектов и добавления новых свойств, по завершении кодиро- 
вания и модульного тестирования разместить изменения в ре 
позитории исходного кода. 


3. Извлечь исходные файлы из репозитория; откомпилировать, о 
скомпоновать или оттранслировать сборку; присвоить сборке 
(внутри нее и в репозитории) номер версии. 


4. Провести приемочное тестирование сборки. Если тестирова- О 
ние завершается успешно, перейти к следующему этапу; если 
тестирование неудачно, выяснить, в чем проблема, исправить 
сборку и вернуться к предыдущему этапу. 


5. Создать инсталлируемый образ сборки на внешнем носителе О 
данных, упаковать его надлежащим образом и передать лицу, 
ответственному за его установку в тестовой среде. 


6. Установить сборку в тестовой среде. а 


7. Провести приемочное тестирование сборки в тестовой среде. о 
Если тестирование завершается успешно, начать тестовый 
цикл. Если тестирование неудачно, деинсталлировать сборку, 
возобновить предыдущий тестовый цикл и вернуть сборку грул- 
пе разработки для повторения процесса, начиная с этапа 1. 


1 В оригинальной версии этой главы, опубликованной под названием “Тезё Ве]еазе 
Ргосеѕѕеѕ” в журнале "сита! о/Зо/їшате Тезійпе Ро/еззіопайз", Моіите 1, Іѕѕџце 2, приведены мно- 
гочисленные цитаты коллег- тестировщиков. Я удалил цитаты, чтобы сохранить общий 
стиль книги, но содержащиеся в них идеи те же. Я бы хотел поблагодарить за полезный 
вклад: Капааі! Вескег, Коѕѕ СоПага, Сагу Оамзоп, Нагусу Юешѕсћ, Тіт Оуез, Раппу Еаџрћ, 
Ревву Еоигѕ, Рагсу Мапіп и Вагіага Киї. 


Глава 12, Передача материалов 335 


Большая сборка поступает в тестовую 
лабораторию 


6 декабря в 14:01 Джамал присоединился к группе управления проектом 
“Суматра” для участия в еженедельном совещании комитета по управле- 
нию изменениями. Одним из вопросов повестки дня было завершение ра- 
боты над составом инкремента 3. По плану инкремент должен быть пере- 
дан на тестирование 13 декабря, а тестирование первой тестовой версии 
должно начаться 16 декабря. Поскольку группа тестирования “Суматры” к 
этому времени уже обнаружила ряд ошибок, Джамал хотел убедиться 
в том, что некоторым из ошибок, замедлявшим проведение тестирова- 
ния, был присвоен достаточно высокий приоритет для первой сборки ин- 
кремента 3. 

Кроме того, поскольку согласно плану разработки в инкремент 3 долж- 
на быть добавлена большая часть оставшейся функциональности, он хо- 
тел проверить, что этот план не поменялся. В самом деле, инженеры- 
тестировщики Эмма Мурхаус и Динеш Кумар назвали первую версию ин- 
кремента 3 “большой сборкой”. Некоторое число тестов было замороже- 
но в ожидании функциональности, запланированной для большой сбор- 
ки. Джамал рассчитывал, что у него есть немного времени на то, чтобы 
обсудить со своей группой приоритеты и логику этих тестов. 

“Итак, — сказала менеджер проекта Кейт Эрнандес, — все на месте”. 
Джамал кивнул, извиняясь за минутное опоздание. “Начнем. Дженни, 
проинформируй о том, что у нас с инкрементом 3”. 

“В целом все очень хорошо, — ответила менеджер разработки Дженни 
Кауфман. — Гораздо лучше, чем это было лишь несколько дней назад. 
Двое моих сотрудников смогли исправить ошибку данных, которую груп- 
па Джамала обнаружила в понедельник в ходе комплексного тестирова- 
ния инкремента 3 и которая мешала правильной работе всей программы. 
И Джон, наконец, понял, как исправить проблему синхронизации, кото- 
рая блокировала работу программы”. 

Кейт бросила на Дженни лукавый взгляд, и Дженни добавила: “Помни- 
те, ее нашла Эмамалини в ходе системного тестирования инкремента 1, 
когда не отвечал менеджер иерархического хранилища? Оказалось, что 
это проблема синхронизации в серверном коде, который взаймодейству- 
ет с сервером управления иерархическим хранилищем”. 

Дженни повернулась к Джамалу и сказала: “Я знаю, Джон уже поблаго- 
дарил Эмамалини, но, пожалуйста, передай ей и от меня спасибо, по- 
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скольку эту ошибку, вероятно, было бы трудно найти, если бы она не на- 
писала небольшой скрипт для воспроизведения отказа». 

Джамал, кивнув, ответил: “Точно, Эмамалини — молодец! Мы должны 
подыскать ей местечко для постоянной работы”. 

Кейт ответила: “Я уже сообщила об этом наверх, Джамал. Я разговари- 
вала с Гарольдом и Джоном, и мы должны обсудить несколько идей после 
совещания. 

Мы думаем, что Эмамалини сможет реально помочь группе разработ- 
ки в подготовке тестовых драйверов для модульного и компонентного 
тестирования”. 

Джамал улыбнулся и подумал о том, что вновь хорошее отношение 
к делу группы сервиса окупается. 

“Но мы здесь собрались не для этого, — подвела итог Кейт, возвраща- 
ясь кглавной теме. — В любом случае, насколько я понимаю, Дженни, это 
означает, что мы завершаем инкремент 3 в срок - в следующую пятницу, 
13 декабря. Это так?” 

“Да, — ответила она. — Я думаю, что так. Остались лишь некоторые из 
расширенных административных функций. Вероятно, нам потребуется 
перенести их на инкремент 4”. 

Еще до того, как Джамал успел поднять руку, Кейт повернулась к нему 
и спросила: “Джамал, что это означает для тестирования?” 

“Не знаю наверняка. Я бы хотел получить список всех свойств, кото- 
рые не должны работать. Некоторые из тестов безопасности и секретно- 
сти пытаются обойти ограничения доступа, чтения, изменения и удале- 
ния объектов, созданные администраторами. Также некоторые из 
функциональных тестов и тестов перегрузки зависят от не являющихся 
иерархическими свойств безопасности, которые должны работать с ад- 
министраторами рабочих групп. Некоторые тесты могут быть заблокиро- 
ваны”, — озабоченно закончил свое выступление Джамал. 

“Я поняла, — ответила Кейт и обратилась к Дженни. — Дженни, после 
обеда подготовь для Джамала список свойств системы, которые могут 
быть не закончены”. Дженни кивнула, соглашаясь. “Джамал, изучи, пожа- 
луйста, список и сообщи мне завтра, как он влияет на тестирование. Если 
действительно есть проблемы, предложи пару вариантов смягчения рис- 
ков для каждого теста, который нельзя выполнить. Дженни, постарайся с 
утра найти время для того, чтобы помочь Джамалу”. И Джамал, и Дженни 
согласно кивнули головами. 

“Хорошо, помимо этих свойств, Дженни, ты разобралась с планом 
и проверила, все ли, что запланировано для инкремента 3, собрано или 
будет готово на следующей неделе?” 

“Да, — согласилась Дженни, — все элементы, кроме свойств, которые мы 
только что обсуждали, либо завершены, либо являются несложными эле- 
ментами с незначительным риском, так что мы не сомневаемся, что они бу- 
дут завершены не позже следующей пятницы, а возможно, и раньше”. 


1 с 
Применение таких методов в реальных проектах рассматривается в статье “Міѕѕіоп 


Маде РоѕѕіЫе”, написанной Рексом Блэком (Кех Віаск) и Грегом Кубачковски (Стер 
КобасгКомѕКі), опубликованной впервые в “$ојїшате Тейтр апі Оцаїйу Епріпеетіпр", МоЇоте 4, 
Іѕѕце 3 ()міу/Ашуе 2002) и доступной в настоящее время на мум.5іскутіпаз.сош и на 
ми гехасксопзШИтв.сот. 
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“Хорошо. Следующий вопрос — отчеты о дефектах. Верно, Джамал?” — 
спросила Кейт. 

“Абсолютно верно. Эта тема мне по душе”, — улыбнулся Джамал. 

“Дженни, пожалуйста, перечисли перечень дефектов, которые соглас- 
но графику должны быть устранены до передачи инкремента 3". 

Дженни стала медленно перечислять дефекты, ожидая комментариев 
и вопросов: “1792, ошибка блокировки файла. 1793, 1798, 1799 и 1800, со- 
общения с ошибками правописания. 1699, ошибка блокировки, обнару- 
женная Эмамалини. 1787 и 1788 оказались дублированными ошибками; 
основная причина ошибки данных одна и та же”. 

Джамал, отмечавший ошибки в своем отчете по ходу выступления 
Дженни, прервал ее: “Ты в этом уверена? Эти ошибки были обнаружены 
при выполнении разных тестовых сценариев на разных данных”. 

Дженни ответила: “Да, я знаю, но на сервере базы данных были стран- 
ные установки конфигурации, мы тут недосмотрели. Оказалось, что там 
есть целый блок ошибок, о которых вы могли бы сообщить, но основные 
пути к ним были заблокированы проблемами в инкременте 3”. 

Джамал пожал плечами и сказал: “Да, возможно, ты права. Не хотелось 
бы прослыть назойливым или предугадывать действия твоей группы, но 
если ты попросишь своих ребят все проверить еще раз, я буду очень при- 
знателен. Эти две ошибки заблокировали огромное число сценариев для 
комплексного тестирования, которые я бы хотел обязательно выпол- 
нить”. 

“Я проверю, — согласилась Дженни и вернулась к списку. Он перечис- 
лила еще десяток ошибок, которые должны быть исправлены. В заверше- 
ние она спросила Джамала: "Есть ли в твоем списке еще какие-нибудь бло- 
кирующие ошибки или накладки, которые я не упомянула?” 

“На самом деле, только одна, — ответил Джамал. — 1815. Я понимаю, 
что это новая ошибка, и просить исправить ее на этой неделе — требовать 
от тебя слишком многого. Но поскольку она не позволяет выполнить 
большую часть тестов с использованием действующих браузеров, я не со- 
мневаюсь, что мы не сможем покрыть несколько важных конфигураций, 
если быстро не исправим ее”. 

“Хм, — сказала Дженни, — мне нужно обсудить этот вопрос со своей 
группой, но, похоже, мы должны с этим справиться. Среднее время за- 
крытия ошибки у нас равно примерно 10 дням, включая накладные расхо- 
ды, связанные с процедурой, верно?” 

“Да, верно, — согласился Джамал, проверяя свои графики, — если это 
обычная ошибка, которая может быть исправлена в стандартные сроки, 
ты сможешь это сделать”. 


№ этапа Этап Выполнено? 


1. Отобрать содержимое для конкретной тестовой версии (ис- М 
правления ошибок, новые свойства и документацию). . 


Участники совещания перешли к другим темам, в том числе к обсужде- 
нию следующих инкрементов. Вскоре после совещания точный перечень 
функций инкремента 3 высокого риска, составленный Дженни, появился 
в почтовом ящике Джамала. Джамал распечатал четыре экземпляра сооб- 
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щения, а затем пригласил Эмму, Динеша и Лин Цу в небольшую перего- 
ворную. 

“Итак, — объяснил Джамал, вручая списки, - в инкременте 3 эти свой- 
ства имеют большой риск. Я хотел бы, чтобы каждый из вас изучил, как 
отсутствие этих свойств или серьезные проблемы в них могут повлиять 
на выполнение ваших тестов, запланированных для инкремента 3. Если 
есть проблемы, попробуйте, пожалуйста, составить план смягчения рис- 
ков или план обходных путей. Пришлите мне результаты вашего анализа 
в середине первой половины дня, хорошо?” 

Все согласно кивнули, и короткое совещание завершилось. На следую- 
щее утро Джамал получил сообщения от Эммы, Динеша и Лин Цу. Все 
предсказывали незначительные проблемы либо их отсутствие, если будут 
задержки с реализацией перечисленных свойств. Джамал быстро собрал 
всех в своем кабинете. “Я бы хотел убедиться в том, что у нас одна точка 
зрения: я посылаю сообщение группе управления проектом о том, что 
группа разработки может перенести эти свойства в инкремент 4”. 

Все кивнули, но Лин Цу добавила: “С обычными предупреждениями, 
верно?” 

Джамал вскинул голову и спросил: “Обычные предупреждения?” 

“Да. Есть риски, которые мы можем предусмотреть, и есть риски, ко- 
торые мы не можем предусмотреть. Из опыта нам известно, что всякий 
раз, когда происходит задержка в получении некоторого свойства на 
тестирование, не сопровождающаяся откладыванием выпуска версии, у 
нас имеется меньше времени на тестирование свойства, а это означает, 
что свойство будет иметь более высокий уровень риска качества при экс- 
плуатации”. 

Джамал согласно кивнул и пробормотал: “Да, конечно”. 

“Кроме того, — продолжала Лин Цу, — есть риски, которые мы не мо- 
жем предсказать. Мы не знаем, как построена система с точки зрения ор- 
ганизации архитектуры, верно? Поэтому мы не знаем, как проявит себя 
отсутствие этих свойств: замаскирует или вскроет поведение других 
свойств”. 

У всех поднялись брови, а Лин Цу продолжила. “Когдабы эти свойства 
ни были добавлены, они могут привести к возникновению других оши- 
бок. Некоторые будут ошибками в новом коде, некоторые окажутся ошиб- 
ками регрессии. Мы не можем точно оценить вероятность этого, по- 
скольку мы не знаем подробностей того, как код, реализующий эти 
свойства, взаимодействует с другими частями системы. Когда эти свойст- 
ва будут добавлены, проблемы, которые сейчас кажутся серьезными, мо- 
гут оказаться менее серьезными. И наоборот. Программы - не автомоби- 
ли. Если у меня проблема с настройкой радио, я могу, по крайней мере, 
предположить, что эта проблема не станет причиной спущенной шины . 
Иногда возникают неразличимые и трудные для предупреждения послед- 
ствия и взаимодействия. Я размышляла по поводу использования итера- 
ционного жизненного цикла и думаю, что чем короче период времени, 


1 Этометкое сравнение позаимствовано из серии изтрех статей Бориса Бейзера “Ѕоћмаге 


із ОШегем», которую можно найти в архиве Зоймаге Кеѕеагсі'ѕ Оџан‹у Тесһпідиеѕ 
М№емѕіейег на ммуг50Й.соп / Мем5 /(ОТМ-Опіїпе / діаргої.Бипі, уулу. зой.сот/Мемз/ОТМ- 
Опіпе/діатаудіВині и лили. ой. сот / Мем5 / ОТМ-ОпНпе/атіша1і В]. 
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в течение которого завершается последняя версия системы, предназна- 
ченная для тестирования, и само системное тестирование, тем больше ве- 
роятность того, что заключительная оценка качества системы — я имею 
в виду то, что происходит на совещании, посвященном завершению сис- 
темного тестирования, - - не будет точной». 

Четыре тестировщика довольно эмоционально отреагировали на это 
заявление. 

“Итак, — продолжала Лин Цу, — я полагаю, что сейчас подходящее вре- 
мя для того, чтобы объяснить группе управления проектом, каково влия- 
ние задержек передачи версии на системное тестирование и на жизнен- 
ный цикл итерационной разработки в целом”. “Не хочу сказать ничего 
плохого об итерационном подходе, — поторопилась добавить она. — До 
сих пор все шло значительно лучше, чем в некоторых других проектах. 
Но риск — это всегда компромисс, не так ли? Чтобы получить небольшое 
пространство для маневра в последней версии, мы, вероятно, должны не- 
много увеличить риск. Полезно заметить, что мы — “группа управления 
рисками качества”, верно?” 

Джамал медленно расплылся в улыбке: “Очень мудрые мысли, Лин Цу, 
особенно о рисках, которые мы не можем предвидеть. Я еще раз расскажу 
об этом Кейт, когда буду писать ей письмо”. 

После этого разговора Джамал подготовил черновик письма Кейт с 
копией для Дженни, в котором объяснил, что поскольку задержка 
свойств администрирования не окажет влияния на тестирование с точ- 
ки зрения его эффективности, можно договориться о смягчении рис- 
ков. Он, в частности, писал: “Как мне подсказала Лин Цу, есть два вида 
рисков: предсказуемые и непредсказуемые. Мы можем предвидеть, что 
меньший объем тестирования этих свойств приводит к большему риску 
при поставке. Мы не можем предсказать, однако, направления, в кото- 
рых отсроченное тестирование системы с полным набором свойств ис- 
кажает точность наших оценок качества. (Между прочим, нужно сделать 
предложение Лин Цу стать менеджером.) Моя группа согласна с тем, что 
мы можем разрешить перенести эти свойства в инкремент 4. Однако, 
если какое-либо из основных свойств, аналогичных этим, не войдет вин- 
кремент 4, советую обсудить на совещаниях группы по контролю над из- 
менениями, можно ли исключить это свойство из последующих версий 
сопровождения”. 

Дженни и Кейт одобрили это сообщение. Джамал был рад услышать, 
как Кейт и Дженни благодарили Лин Цу за ее наблюдательность. 

Утром в пятницу Дженни отправила письмо группе управления проек- 
том, сообщающее о том, что инкремент 3 помещен в проектный репози- 
торий. Она приложила к письму список изменений в версии. К счастью, 
только одного из шести свойств повышенного риска не было в новом ин- 
кременте. Она попросила менеджера сборки версий Ясухиро Канагаву 
подготовить версию и провести приемочное тестирование как можно 
быстрее, чтобы она смогла в этот же день или в предстоящие выходные, 
если потребуется, найти и разрешить возникшие проблемы. 

Пару часов спустя Ясухиро прислал короткое сообщение: “Версия от- 
личная. Результаты приемочного тестирования прилагаются. Кейт, по- 
жалуйста, договорись с Джамалом об установке”. 


Часть Ш. Проведение 


№ этапа Этап Выполнено? 


2. Реализовать изменения, необходимые для исправления де- М 
фектов и добавления новых свойств, по завершении кодиро- 
вания и модульного тестирования разместить изменения в ре- 
позитории исходного кода. 


3. Извлечь исходные файлы из репозитория; откомпилировать, 
скомпоновать или оттранслировать сборку; присвоить сборке 
(внутри нее и в репозитории) номер версии. 


4. Провести приемочное тестирование сборки. Если тестирова- м 
ние завершается успешно, перейти к следующему этапу; если 
тестирование неудачно, выяснить, в чем проблема, исправить 


ее и вернуться к предыдущему этапу. 


Кейт и Джамал столкнулись на пути к друг к другу и рассмеялись. “Бли- 
зится вечер пятницы, а, Кейт?” — пошутил Джамал. 

“Не похоже, что ты собираешься здесь торчать после пяти, пижон”, — 
ответил Кейт. 

“Ты прав. Не собираюсь. Семья приезжает на выходные, и я должен 
быть с ними. Это Остин, поэтому здесь много развлечений в пятницу ве- 
чером”. | 

“Еще бы! Итак, — сказал Кейт, переходя к делу. — Какой у нас план?” 

“Я бы предложил сделать, как раньше? У нас есть принятый процесс 
для установки сборок, поэтому будем следовать ему. Если ты не думаешь, 
что раньше были проблемы?” 

“Нет-нет, я думаю, что он отлично работает, Джамал, — ответил 
Кейт. — Ты прекращаешь тестирование в 4 часа дня, а я затем прошу Пет- 
ру установить сборку. Как только она закончит, думаю, не позже, чем че- 
рез час, твой младший тестировщик... Напомни, как его зовут?” 

“Дейл”. 

“Верно, Дейл. Дейл сможет запустить приемочный тест в тестовой 
среде перед уходом с работы”. 

“Отличный план”, — сказал Джамал. 

“Конечно, я думал о нем, — пошутил Кейт. — Петра и Дейл уже догово- 
рились о деталях, поэтому я думаю, что мы должны предоставить им кре- 
дит доверия”. 

“Знаешь, — сказал Джамал, — есть управленческое клише: нет конца 
процессу кредитования, если Вы не следите за тем, кто получает кредит. 
На самом деле более точной является фраза: нет конца процессу креди- 
тования, если Вы не следите за тем, когда сообразительные люди делят 
кредит”. 

“Подписался бы под этой фразой, — ответил Кейт. — В любом случае я 
собираюсь сказать Петре, чтобы она ждала твоего звонка, хотя не сомне- 
ваюсь, что онауже ждет. Ты планируешь заехать в выходные и проверить 
результаты приемочного тестирования?” 

“Возможно, я проверю их через Интернет. Нет смысла приезжать в 
выходные в офис, если проект идет так хорошо”. 

Проект и дальше шел хорошо. Перед тем как Джамал отправился в аз- 
ропорт Остина встречать семью, он подошел к Дейлу. 

“Как там приемочный тест, Дейл?” 
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“Уже запущен. Пока проблем не возникло”. 

“Похоже, вы с Петрой наладили процесс?” 

“Она инсталлирует, я запускаю приемочный тест, а потом мы все тес- 
тируем. Все просто, как дважды два”, — ответил Дейл, улыбаясь. 

“Думаю, что хороший процесс всегда прост, Дейл. Чтобы так поум- 
неть, пришлось убить немало проектов, но мы становимся умнее благода- 
ря упрощению”. Й 

“Хороших выходных, босс”, — сказал Дейл. 

“Да, и тебе тоже, Дейл”. — Джамал взглянул на часы. Они показывали 
16:50. Джамал улыбнулся и пошутил: “Знаешь, Дейл, учитывая твою на- 
пряженную работу, почему бы тебе ни отдохнуть остаток дня?” 


№ этапа Этап Выполнено? 


5. Создать инсталлируемый образ сборки на внешнем носителе 


данных, упаковать его надлежащим образом и передать лицу, 
ответственному за его установку в тестовой среде. 


| 


6. Установить сборку в тестовой среде. 


[а] 


7. Провести приемочное тестирование сборки в тестовой сре- 
де. Если тестирование завершается успешно, начать тесто- 
вый цикл; если тестирование неудачно, деинсталлировать 
сборку, возобновить предыдущий тестовый цикл и вернуть 
сборку группе разработки для повторения процесса, начиная 
с этапа 1. 


я 


Построение успешного процесса подготовки 
тестовых версий 


Как отметил наш вымышленный герой Джамал, хороший процесс прост, 
но это не значит, что создать хороший и простой процесс также просто. 
Участвуя в большом количестве проектов, я заметил, что это особенно вер- 
но для управления тестовыми версиями. Есть общий соблазн передать по- 
скорее то, что сделано, на тестирование, как будто разработка программ — 
это форма позиционной войны. Требуется тщательное и вдумчивое отно- 
шение к внедрению качественного процесса подготовки тестовых версий. 
Давайте посмотрим, что делает и чего добивается проектная группа, при- 
меняя качественный процесс сборки версий для тестирования. 


Подготовка инсталлируемых, усовершенствованных 
и стабильных тестовых версий 


Однажды я работал с компанией, в который был выстроен отменный про- 
цесс взаимодействия с заказчиками. Когда я отправлял запросы при по- 
мощи быстрого, автоматизированного меБ-сайта, она присылала прият- 
ные письма о своей приверженности качеству и решению моих проблем. 
Была только одна помеха: они не оказывали качественных услуг. Они не 
решили ни одной из проблем, о которых я сообщил их службе поддержки 
клиентов. Поэтому я больше не являюсь заказчиком этой компании. 
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То же самое применимо к процессу подготовки тестовых версий. Клю- 
чевым индикатором хорошо поставленного процесса является то, что 
процесс каждый раз завершается передачей сборки, пригодной для тес- 
тирования. Все другие признаки качественного процесса могут присутст- 
вовать. Но предположим, что каждая тестовая версия превращается в 
кошмар из-за впустую потраченного времени на установку сборки, из-за 
путаницы при регрессионном тестировании и позорной ямы заблокиро- 
ванных тестов, аварий в середине тестирования и других показателей не- 
стабильности. Разве вы не придете к выводу, что процесс сборки версий 
имеет серьезные проблемы? 

Качественный процесс подготовки тестовых версий передает сборку, 
которая может быть инсталлирована. Процесс инсталляции должен, по 
крайней мере, разместить элементы сборки в соответствующих местах, 
с соответствующими правами доступа и в правильном порядке. Если для 
успешной установки требуется выполнение предваряющих инсталляцию 
или последующих за ней действий, они должны быть либо автоматизиро- 
ваны, либо документированы надлежащим образом для сотрудников, ко- 
торые будут заниматься установкой. Для многих системных сред, вклю- 
чая МіпӢоиѕ и ОМІХ, существуют коммерческие инструменты для 
создания инсталлируемых версий и пакетов. 

Качественный процесс подготовки тестовых версий должен переда- 
вать сборку, которая лучше предыдущей. Это означает, что то, что работа- 
ло раньше, по-прежнему работает, и что часть сборки, которая не работа- 
ла раньше, работает лучше, чем в предыдущих тестовых версиях. 
В главе 15 будут рассмотрены два индикатора того, что проект подходит к 
успешному завершению. Это устойчивое сокращение общего числа от- 
крытых дефектов и постепенное уменьшение числа новых дефектов, об- 
наруживаемых в очередной версии. Таким образом, общая тенденция 
должна быть такой, что происходит улучшение состояния системы от 
версии к версии. 

Общая тенденция улучшения версий частично является результатом 
тщательной разработки и исправления ощибок программистами. В од- 
ном из проектов примерно 20% отчетов о дефектах были повторно от- 
крыты хотя бы однажды, т.е. ошибки, о которых разработчики говорили, 
что они исправлены, либо не были на самом деле исправлены в тестовой 
версии, либо в одной из версий были исправлены, а затем возникли сно- 
ва. Тестировщикам пришлось заново открывать один из отчетов о дефек- 
тах десять раз! Основные процессы, программирование и отладка, долж- 
ны сопровождаться адекватным модульным, компонентным и, если 
необходимо, комплексным тестированием. 

Лучший способ, который я когда-либо встречал для таких видов тести- 
рования, предполагает участие разработчиков в подготовке тестовых 
сценариев для кода по мере его написания, а затем помещение тестовых 
сценариев вавтоматизированные тестовые драйверы для проверки кода. 
Это непрерывно растущее множество тестов выполняется для каждой 
сборки в качестве элемента процесса сборки с целью проверки того, что 
отдельные части сборки работают верно. (Вообще говоря, качественное 
тестирование силами разработчиков, особенно на фазах модульного 
и компонентного тестирования, — это один из признаков качественного 
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процесса тестирования, как будет показано в главе 17.) Этот метод, яв- 
ляющийся общепринятой практикой уже в течение десяти лет, в настоя- 
щее время получает признание в связи с приходом различных методоло- 
гий быстрой разработки программ, которые усилили идеи разработки с 
первоначальным тестированием и применения автоматизированных 
тестовых драйверов . 

Другое усовершенствование процесса — это тщательный контроль из- 
менений и управление конфигурациями программного продукта. Если 
два сотрудника работают с одним и тем же модулем одновременно, без 
библиотеки, управляющей исходных кодом, используя многочисленные 
копии дерева кода в различных папках и на разных серверах и выполняя 
прочие хаотические действия над составляющими систему компонента- 
ми, это естественным образом ведет к сборке неудачных версий. Нет кон- 
ца бедствиям, которых можно избежать за счет простого, облегченного 
режима конфигурационного управления. Наряду с организацией модуль- 
ного, компонентного и комплексного тестирования при помощи тесто- 
вых драйверов, это еще один лучший метод организации работ, который 
завоевал популярность в последние десятилетия". 

Сейчас даже при наличии инсталлируемых сборок, проведении качест- 
венного модульного, компонентного и комплексного тестирования и эф- 
фективном управлении конфигурацией программного обеспечения сущест- 
вует вероятность передачи группе тестирования неудачной сборки. Иногда 
фрагменты работают по отдельности, но как только их объединяют вместе, 
возникают проблемы, которые проявляются только в определенных частях 
продукта и при определенных условиях. Многие из нас слышали смущенный 
возглас программиста: “В моей системе это работает отлично”. 

Конечно, до передачи системы на тестирование невозможно гаранти- 
ровать, что она пройдет успешно все тесты. Если бы мы могли это гаран- 
тировать, нам не нужно было бы ее тестировать. Однако правило 80/20 
поможет избежать напрасной траты времени". Большая часть серьезных 
проблем — ситуации, блокирующие дальнейщее выполнение тестов, крах 
системы, разрушение целостности данных — обнаруживаются в первые 
часы тестирования. Это особенно верно, если вы начинаете с широкого 
покрытия. Это правило является движущей силой, в дополнение к идее 


ти Гленфорд Майерс в книге “Искусство тестирования программ”, впервые опубликован- 


ной в 1979 г., и Фред Брукс в книге "Мифический человеко-месяц", опубликованной впервые 
в 1975 г., рассматривают тестовые драйверы. Современные тестовые драйверы исследуют- 
ся в статье "Міззіоп Маде РоѕѕіЫе”, упомянутой ранее. 


В моем первом проекте разработки для МХ в 1983 г. применялся строгий процесс кон- 
фигурационного управления под контролем библиотекаря, использовавшего утилиту $СС$. 
Даже тогда это был проверенный десятилетиями опыт организации работ. Фред Брукс опи- 
сывает систему “библиотеки программ и учета”, которая применялась в проекте ВМ 
05/360, в главе “Острый инструмент” книги “Мифический человеко-меся”. 


3 Правило 80/20 существует в разных вариациях. Я использую версию для менеджмента, 
суть которой состоит в том, что 80% прибыли от любой деятельности обычно приносят пер- 
вые 20% затрат на нее. Правило 80/20 более формально называется принципом Парето, ко- 
торый в нынешнем виде был впервые описан Дж. М. Джураном (|. М. Тагап). Интересное об- 
суждение этого правила и его приложений к тестированию см. в статье Эрика Петерсена 
(Егік Регегѕеп) “Ѕтпагсег Теѕіпр Оѕіпо Ше 80/20 Еше” в “Руосеебіпру оў йе ЅТАВ Уея 2002 
Сопјегепсе', доступной на ууу.51сКутіпаѕ.сот. 
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приемочного тестирования. Еще раз повторю, что это не новая идея, по- 
скольку в конце 80-х годов я работал в проекте, в котором активно приме- 
нялось приемочное тестирование, встроенное в процесс сборки версий. 


Подготовка предсказуемых, своевременных и регулярных 
тестовых версий 


Даже при условии, что новая версия является инсталлируемой, улучшен- 
ной и стабильной, приемка ее на тестирование означает необходимость 
в проведении ряда действий. Тест-менеджер должен обсудить с группой 
тестирования, какие тесты они должны выполнить для этой сборки. Кто- 
то должен установить версию, загрузить все необходимые файлы с дан- 
ными, возможно, обновить некоторые базы данных или модифициро- 
вать зависимые системные конфигурации. В случае установки клиент- 
серверных и других многоплатформенных систем инсталляция новой 
версии может означать ее установку на нескольких машинах. Иногда име- 
ет значение порядок установки. Группа тестирования должна убедиться, 
что тестовая версия готова к тестированию. Если это не так, группа тести- 
рования должна подготовить ее, например, установив заплатку на про- 
дукт на лету, исправив ранее необнаруженную проблему конфигурации 
тестовой среды и т.п. Если мы не можем подготовить тестовую версию, то 
группа тестирования должна удалить ее из тестовой среды. Как только го- 
товы правильно установленная тестовая версия и тестовая среда, группа 
тестирования обычно получает полномочия на проведение проверочно- 
го тестирования, цель которого удостовериться в том, что ошибки, о ко- 
торых было заявлено, исправлены, действительно устранены. Пройдя 
через все эти этапы, группа тестирования возобновляет плановое тести- 
рование. В некоторых случаях сначала мы хотим провести полное регрес- 
сионное тестирование (заново выполнить все ранее проведенные тесты 
или перетестировать все ранее проверенныеусловия). Если группа тести- 
рования отвечает за выполнение нескольких проектов тестирования од- 
новременно, поступление на тестирование сборки наиболее важного 
проекта может приостановить тестирование в других проектах, что тре- 
бует существенного и рискованного переключения всех или части сотруд- 
ников группы тестирования на другой контекст. 

Многие группы тестирования работают именно так. В этих обстоя- 
тельствах установка новой версии не является легким решением. По- 
скольку она прерывает и изменяет плановое тестирование, я и многие 
другие менеджеры, с которыми я общался, считают нежелательным появ- 
ление тестовых версий в незапланированные сроки. Также из-за наклад- 
ных расходов, связанных с установкой новой сборки, их частая архива- 
ция может серьезно повлиять на скорость работ по тестированию. Чем 
чаще поступают тестовые версии, которые полны ошибок, нестабильны 
или неинсталлируемы, тем более это замедляет процесс подготовки тес- 
товых версий. (В таких случаях требуется проведение приемочного тес- 
тирования для тестовых версий до их передачи на тестирование.) 

Однако, поскольку тестирование несвежей (т.е. устаревшей) тестовой 
версии может привести к формированию отчета об уже исправленных де- 
фектах, существует также вероятность получения тестовых версий слиш- 
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ком редко. Если для выполнения всех тестов требуется много времени, 
вы, возможно, захотите принять очередную тестовую версию до заверше- 
ния выполнения всех тестовых сценариев. 

Вернемся к теме тестовых версий, раундов и циклов (см. главу 3). По- 
скольку передача тестовой версии является началом последующего тесто- 
вого цикла, наличие ожидаемых и регулярных тестовых версий позволя- 
ет группе тестирования спланировать работу с версиями. Обратите 
внимание, как Джамал спланировал периоды проверочного, планового и 
исследовательского тестирования в рамках каждого тестового цикла (см. 
рис. 12.1). Регулярность действий позволяет ему сделать прогноз, сколько 
времени потребуется для проведения тестового раунда, поскольку он мо- 
жет добавить в план известный объем накладных расходов на сборку тес- 
товых версий. Он может спланировать менее насущные, но не менее важ- 
ные действия, такие как обновление тестовых сценариев и данных, 
настройка автоматизированных тестовых скриптов. Регулярное и плано- 
вое поступление тестовых версий позволяет тест-менеджеру спланиро- 
вать заранее рабочую неделю и выделить время для различных работ. 

И наоборот, проекты, в которых отсутствуют предсказуемость и регу- 
лярность передачи тестовых версий, часто платят большую цену за то, 
что кажется гибкостью. Эта цена включает в себя неэффективное и нера- 
циональное тестирование, выполняемое спешащими людьми при помо- 
щи некачественных средств тестирования в ненадежной тестовой среде 


Группы программистов 
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одготовка сборок 
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«Кандидат в золотую сборку» 
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Рис. 121. Тестовые раунды, циклы и версии 


346 


Часть Ш. Проведение 


с попытками учесть последние изменения в плане. Хаотический и непред- 
сказуемый процесс подготовки тестовых версий разъедает все другие 
процессы, описанные в этой книге. В компаниях часто не понимают, что 
процессы, снижающие общую эффективность команды, не могут повы- 
сить гибкость, они уменьшают ее, забирая энергию, концентрацию и наи- 
более ценный проектный ресурс - время. 

В одном из наиболее успешно управляемых проектов, в которых я уча- 
ствовал, группа разработки приступала к заключительной стадии разра- 
ботки согласованного содержимого версии в пятницу, и к субботнему ве- 
черу код был готов. Менеджер сборки приходил в воскресенье утром, 
имы получали тестовую версию в воскресенье днем. Ко времени заверше- 
ния смены в воскресенье вечерому нас была установленная тестовая вер- 
сия, прошедшая приемочное тестирование и готовая к тестированию 
в понедельник утром. 

Когда различные проекты борются за единственное множество ресур- 
сов тестирования, координация усилий становится более критической 
и более сложной. Только один хаотический проект, использующий не- 
предсказуемые тестовые версии, может разрушить всю организацию тес- 
тирования. Один тест- менеджер вспоминал об этом, как “о наезде поезда, 
груженного плохим проектом”. 

Заметим, что в нашем примере Джамал делит свою группу и различ- 
ные конфигурации тестовой среды на подгруппы и конкретные конфигу- 
рации, нацеленные на реализацию отдельных проектов, включая новую 
версию ЅреедуМтгіег и тестирование версий сопровождения для преды- 
дущих версий пакета О сеАгго\у. Считаю такое деление на базе проектов 
полезным в том случае, когда есть проекты, которые могут внести в по- 
следний момент много изменений в расписание тестовых версий. Любое 
предложение о перераспределении ресурсов из одного проекта в другой 
является предметом обсуждения, к которому я могу привлечь конкури- 
рующих за услуги группы тестирования менеджеров проектов. Называй- 
те меня Макиавелли, но я считаю, что сохранить мой политический капи- 
тал позволяет предоставление права другим сказать мне “нет” всякий раз, 
когда это возможно. При наличии ограниченных ресурсов менеджер про- 
екта, который настаивает на том, что ему нужна свобода в передаче тесто- 
вых версий на тестирование тогда и так часто, как он хочет, может созда- 
вать отрицательные последствия только для его проекта, а не для 
проектов других менеджеров. 

Все это не означает, что у вас может быть единый, универсальный про- 
цесс сборки тестовых версий для всего, что поступает в тестовую лабора- 
торию. Процесс, показанный на рис. 12.1, подходит для проекта разра- 
ботки в рамках итерационного жизненного цикла, комплекта тестов, 
который может быть выполнен от начала до конца за пару недель, и для 
стабильного продукта, который не требует большого объема регрессион- 
ного тестирования для каждой тестовой версии. В проектах с каскадным 
жизненным циклом или с У-моделью инкременты не подойдут. Наилуч- 
ший опыт тестирования версий сопровождения я получил, когда группе 
тестирования была передана первая версия с полностью реализованны- 
ми свойствами, после чего в течение недели было проведено тестирова- 
ние и исправление обнаруженных ошибок. Затем поступила вторая вер- 
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сия и прошла еще неделя тестирования, и наконец была выделена неделя 
тестирования версии для заказчика, после того как она прошла процесс 
сборки версий. 

Иногда требуется тестировать аварийные патчи, которые содержат 
исправление одной-двух ошибок и должны быть разработаны в течение 
недели, а иногда и одного дня. Это очень рискованные предприятия, 
и ключом к ним является выбор разумной стратегии тестирования, кото- 
рая уравновешивает все параллельные риски. Возможно, вы передаете 
аварийные патчи только тем заказчикам и пользователям, которые стал- 
киваются с проблемой, а затем включаете эти патчи в следующую версию 
сопровождения после тщательного регрессионного тестирования. 

Как видите, различные обстоятельства, в том числе различные фазы 
системного жизненного цикла, могут оказывать значительное воздейст- 
вие на процесс подготовки тестовых версий. Здесь может помочь специ- 
ально разработанное множество стандартизованных процессов в соот- 
ветствии с рекомендациями этой книги. Можно один раз придумать 
качественный процесс, а затем многократно использовать знания вместо 
того, чтобы делать это каждый раз заново. 


Использование четко определенных процессов инсталляции 
и деинсталляции, похожих на те, что применяет пользователь 


Ранее я упоминал о том, что версия должна быть как минимум инсталли- 
руемой. Но качественный процесс подготовки тестовых версий включа- 
ет в себя процедуру установки, которая четко определена. Кроме того, 
в ходе фазы системного тестирования и на последующих фазах тестиро- 
вания я предпочитаю использовать процесс подготовки тестовых вер- 
сий, который использует ту же процедуру инсталляции, что и заказчики 
и пользователи в процессе эксплуатации системы. (Процедура предпола- 
гает тестирование с теми же видами прав и учетных записей.) Я также 
предпочитаю наблюдать и проводить тестирование процесса деинстал- 
ляции тестовой версии, потому что заказчики или группа поддержки сис- 
темы, вероятно, должны это делать и потому что может возникнуть необ- 
ходимость откатить плохую тестовую версию. 

Сложность процесса инсталляции часто является функцией системы, 
предназначенной для тестирования (см. ниже). Приложение МЙпдомз, 
как правило, имеет прямой процесс установки, тогда как сложные вари- 
анты конфигурации сред с многочисленными серверами, иногда распре- 
деленными по глобальной сети, часто требуют для установки больших за- 
трат человеко- часов. Тем не менее во всех случаях процесс инсталляции 
должен быть как можно более простым. Простые процессы менее подвер- 
жены ошибкам и, следовательно, с большей вероятностью быстрее при- 
водят к созданию тестопригодной конфигурации. Также простые процес- 
сы обычно требуют привлечения меньшего числа людей. Возможность 
неправильного взаимодействия, несогласия и возникновения политиче- 
ских вопросов возрастает с ростом числа людей и групп, вовлеченных 
в процесс, что увеличивает сложность, продолжительность и вероят- 
ность сбоев в любой деятельности. 
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Если процесс достаточно прост, группа тестирования может выпол- 
нить работу самостоятельно. Это позволяет группе тестирование прове- 
рить сами процессы инсталляции, деинсталляции, обновления и установ- 
ки патчей. В случае использования архивированной программы часто 
необходимо провести тестирование инсталляции на разнообразных сис- 
темных конфигурациях. Для ІТ- программ среда не может изменяться, но 
варианты, связанные с порядком исполняемых инсталляций или измене- 
ний баз данных, использования процессов установки патчей, обновления 
и первоначальной инсталляции и т.п., приводят к созданию разнообраз- 
ных тестовых условий. Процесс инсталляции должен покрывать все эти 
тесты, таким образом избавляя группу тестирования от большой и ненуж- 
ной работы по тестированию инсталляции, которая должна проводиться 
в ходе тестового цикла. Все-таки вам придется когда-то инсталлировать 
версии. 

Процесс деинсталляции — это в лучшем случае вариант процесса ин- 
сталляции. Для приложений У/іпдом5, например, панель управления 
обеспечивает доступ к обеим функциям, а пакеты в формате шуа$ ме! 
поддерживают удаление файлов и изменений реестра в качестве пунктов 
меню. Для 501аг15 аналогичные функции предоставляют утилиты управ- 
ляющего пакета рраа4и ркртт. В некоторых случаях применение утилиты 
построения образов диска, например СПозі, дает возможность группе 
тестирования сохранить чистые образы систем, в которые они могут ус- 
танавливать любые версии. Однако в некоторых очень сложных средах 
откат изменений может быть гораздо более сложным, чем установка, 
если не существует инструментов управления конфигурацией, которые 
могут надежно откатывать любую последовательность изменений систе- 
мы. Тем не менее я однозначно выступаю за средства деинсталляции. 
Я сталкивался с проектами, в которых не было такой возможности, и в ре- 
зультате версии с ошибками разрушали тестовую среду, что приводило, 
как минимум, к неделе простоя, пока шло восстановление всей тестовой 
среды, включая операционную систему, сопутствующие программы 
и предыдущую версию системы, предназначенную для тестирования. 
Я слышал аналогичные истории и от других тестировщиков, так что нель- 
зя назвать это моим личным невезением. 

Довольно давно в проекте сетевой операционной системы ОХ я на- 
блюдал, как хорошо выполнялся процесс инсталляции и деинсталляции. 
В качестве аппаратной среды использовались разнородная сеть мэйн- 
фрейм/Р5-2 с инфраструктурой Ефегпе! и кольцо с маркерным доступом 
(соКер гіпӯ). Интегрированная программа, запускавшаяся с одного серве- 
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ра, могла 1) установить свежую версию операционной системы на форма- 
тированные жесткие диски на одном и более серверах или рабочих стан- 
циях; 2) обновить существующие серверы или рабочие станции новыми 
версиями или патчами; 3) откатить обновления и патчи. В ходе системно- 
го тестирования мы варьировали процесс каждую неделю, чтобы охва- 
тить все возможные комбинации, сначала устанавливая версию для тести- 
рования на чистое оборудование, а по завершении фазы системного 
тестирования проводя систематическое тестирование средств инсталля- 
ции и деинсталляции в операционной системе. 


Присвоение имен тестовым версиям 


Тестовая версия, поступающая из большой системы управления конфигу- 
рациями, как правило, имеет идентификатор или номер версии. В идеале 
тестировщику должна быть доступна простая команда, позволяющая по- 
лучить номер версии из самой системы, предназначенной для тестирова- 
ния. Например, в большинстве приложений УЛпдомз выбор меню По- 
мощь/О программе открывает экран, показывающий номер версии. 

Это важно, потому что, за возможным исключением приемочных тес- 
тов, тестировщики выполняют тесты на многих версиях и находят ошиб- 
ки в каждой из версий. Они вводят ошибки в систему управления дефекта- 
ми (см. главу 14). В отчете о дефекте тестировщик должен указать версию, 
содержащую ошибку. Без этой информации разработчикам трудно лока- 
лизовать корневую причину среди многих изменений в коде, особенно 
если симптом отказа некоторым образом изменяется от одной версии к 
другой. Кроме того, менеджеры, вероятно, будут иметь проблемы при по- 
лучении измерений числа ошибок, найденных в версии. 

По этим причинам для любого продукта, передаваемого на тестирова- 
ние, необходимо соглашение об именовании версий. Соглашение об име- 
новании не обязательно должно иметь смысловую нагрузку. Можно, веро- 
ятно, назвать версии Фред, Зедедиа, Эмамалини. Однако я предпочитаю 
видеть упорядоченность и простоту в способах именования версий. Что- 
бы начать последовательность, мы можем использовать такие шаблоны, 
как А, В, Сит.д. или 0001, 0002, 0003 ит.д. Первый подход довольно слаб, 
поскольку перечень букв может иссякнуть либо по достижении 7 превра- 
титься в АА, АВ, АС ит.д. Я наблюдал, как в одном успешном подходе к 
управлению версиями мой клиент использовал для обозначения версий 
четыре цифры. Тестовые версии появлялись каждый вечер, подверга- 
лись приемочному тестированию и использовались разработчиками в ка- 
честве основы для дальнейшей работы. Один раз в неделю менеджер сбо- 

‚ рок передавал проверенную ночью версию группе тестирования. Таким 
образом, мы получали версии с номерами, отличавшимися на 7 единиц, 
например, 0103 для одного тестового цикла, 0110 — для второго, 0117 — 
для третьего и т.д. Иногда номера версий отличались более чем на 7 еди- 
ниц, поскольку разработчики повреждали сборку и в этот день появля- 
лось больше одной версии. 

Большое разнообразие последовательностей имен является работо- 
способным, если любое изменение добавляет единичку к номеру версии. 
Всякий раз, когда состав библиотеки исходного кода изменяется, а номер 


350 


Часть ІЙ. Проведение 


версии нет, две тестовые версии с одним и тем же номером не являются 
одинаковыми и могут вести себя по-разному. Еще хуже, когда исходный 
код в репозитории не меняется, а тестовая версия меняется, поскольку 
кто-то не положил измененный модуль в библиотеку. Это путь к хаосу в от- 
четах о дефектах и к невоспроизводимым ошибкам, что, безусловно, оз- 
начает неэффективное и нерациональное проведение тестирования. 

Заметим, что тестировщик не должен знать с точностью до отдельно- 
го файла, что означают номера версий множества компонентов. Важно, 
чтобы разработчики могли разобраться в этом, обычно при помощи сис- 
темы управления исходным кодом. Я отдаю предпочтение единственно- 
му номеру версии. Инструмент, работающий с репозиторием, может со- 
поставить этот номер номерам версий отдельных компонентов и, если 
необходимо, конкретным изменениям исходных файлов. 

Помимо схем логического именования, тестировщик должен уметь ус- 
танавливать номер тестовой версии при помощи самой версии. Я предпо- 
читаю методы, позволяющие делать запрос к системе. В качестве приме- 
ра вновь можно привести стандарт УЛп4омз для экранов Помощь/О 
программе. Если совокупность символов не извлекается из программы, 
тестировщик может найти наименование при помощи утилиты 545. 
При любом подходе, конечно, процесс подготовки тестовых версий дол- 
жен включать в себя автоматизированный или ручной способ изменения 
этого именования при переходе от одной версии к другой. 

В некоторых случаях можно запросить не саму систему, а систему, ко- 
торая ее обновляет. Рассмотрим следующий пример. Однажды я тестиро- 
вал клиент-серверную систему, в которой программы, выполнявшиеся на 
клиентах, поступали с одного сервера. Этот сервер имел базу данных, ко- 
торая содержала идентификатор клиентского устройства и номер по- 
следней тестовой версии, установленной на устройстве. Запрашивая сер- 
вер, тестировщики знали, какая версия программы выполнялась на 
каждом из данных клиентов. 

Возвращаясь на минуту к теме инсталляции и деинсталляции, отмечу, 
что эта система также обеспечивала простой интерфейс в виде команд- 
ной строки, позволявший изменять версию, которая направлялась на 
клиентские машины при их очередном соединении с сервером, как на 
предыдущую (деинсталляция), так и на последующую (инсталляция). Вот 
отличный, высококачественный и непротиворечивый интерфейс для 
инсталляции, деинсталляции и запросов. Данный пример показывает, 
что при некоторой предусмотрительности простая, но мощная утилита 
может решить много различных проблем, связанных с управлением вер- 
сиями, даже в сложной среде. 


Подготовка сборки из тщательно отобранных, 
скоординированных и документированных компонентов 


Для иллюстрации проблем, связанных с управлением содержимым тесто- 
вой версии, рассмотрим следующую гипотетическую ситуацию. Цикл сис- 
темного тестирования начинается с тестирования данной версии. В тече- 
ние недели группа тестирования находит и информирует о 30 проблемах 
в версии, каждая в отдельном отчете о дефекте. Кроме того, представите- 
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ли группы продаж, маркетинга или бизнеса поместили шесть запросов на 
усовершенствование, т.е. на новые свойства для настройки продукта для 
определенных сегментов заказчиков и пользователей. Вместе эти доку- 
менты дают возможность группе проекта улучшить качество продукта. 
Чтобы обеспечить производительность и эффективность, проектная 
группа должна тщательно управлять процессом. Повышение качества 
продукта на основе 36 запросов нуждается в процессе, который последо- 
вательно рассматривает три вопроса. | 


1. Как группа управления проектом решает, какие из 36 потенциаль- 
ных изменений являются кандидатами на включение в очередную 
тестовую версию? 


2. Как группа разработки уведомляет группу тестирования о том, ка- 
кие изменения в поведении системы, по их мнению, будут реализо- 
ваны посредством изменения кода? 


3. Как группа тестирования информирует группу разработки о со- 
стоянии успешного или неудачного изменения кода: изменение 
реализовано без связанной регрессии, изменение реализовано, но 
со связанной регрессией, изменение не реализовано верно? 


На рис. 12.2 показан процесс управления этими проблемами. В этом 
процессе отчеты о дефектах и запросы на усовершенствование рассмат- 
риваются на совещании с участием специалистов разных направлений. 
На этом совещании группа управления проектом, включая разработчи- 
ков, тестировщиков, специалистов по продажам и маркетингу, спонсо- 
ров, специалистов по технической поддержке или поддержке пользова- 
телей и, возможно, операций, оценивает затраты и преимущества 
каждого предлагаемого исправления ошибки и потенциального усовер- 
шенствования. Эту группу специалистов разного профиля обычно назы- 
вают группой по управлению изменениями. (Процесс управления изме- 
нениями рассматривается в главе 16.) 

Выбор содержимого версии оказывает влияние как на систему, пред- 
назначенную для тестирования, так и на процесс тестирования в данном 
цикле. Например, некоторые пропущенные свойства или исправления 
дефектов могут иметь особое значение, поскольку они блокируют ключе- 
вые тесты, как отмечал Джамал в рассматриваемом нами примере. Эти 
тесты в случае задержки их выполнения до конца процесса тестирования 
могут привести к обнаружению в последний момент критических оши- 
бок. Кроме того, в некоторых моделях жизненного цикла разработки, на- 
пример в эволюционной модели, используемой в нашем примере, про- 
ектная группа собирает состав версий таким образом, чтобы в конце 
каждого тестового цикла она могла получить систему, которую можно по- 
ставить или развернуть. 

В конце совещания достигается предварительное соглашение о том, 
какие изменения будут и не должны быть реализованы. Я использую сло- 
во “предварительное” по двум причинам. Во-первых, поскольку старшие 
и топ- менеджеры, вообще говоря, считаются с мнением группы управле- 
ния проектом по поводу управления дефектами и процесса выбора усо- 
вершенствований, иногдау них также бывают любимые свойства или лю- 
бимые жалобы, которые, по политическим причинам за отсутствием 
других, проектной группе приходится учитывать. Во-вторых, группа раз- 
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Рис. 12.2. Процесс управления изменениями и тестовыми версиями 
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работки не может обычно завершить реализацию всех изменений вовре- 
мя к выпуску следующей версии. Некоторые изменения требуют больше 
времени, чем другие. Некоторые оказываются при ближайшем рассмот- 
рении более сложными, чем считалось сначала. 

Группа разработки переходит к реализации предложенных измене- 
ний и передаче тестовой версии. Кроме того, группа тестирования долж- 
на получить информацию об изменениях, содержащихся в версии. 
Информация об изменениях показывает, какие из предложенных изме- 
нений реализовала группа разработки. Я встречал разные способы непло- 
хой работы по подготовке информации об изменениях. В тех случаях, ко- 
гда проектная группа работала с надежным инструментом управления 
дефектами и усовершенствованиями, информация об изменениях в вер- 
сиях предоставлялась при помощи этого инструмента. В некоторых про- 
ектах по разработке приложений для ОМІХ и мер-приложений группа 
проекта передавала информацию об изменениях в виде текстового файла 
как часть пакета, содержащего тестовую версию. Эти документы, часто 
называемые файлами теа4те, могут содержать ссылки на идентификато- 
ры дефектов или просто перечислять изменения. Автоматизация и воз- 
можность отслеживания упрощают сбор и подготовку информации о вер- 
сии, но отсутствие таких инструментов не устраняет необходимости 
в информации об изменениях в версии. Я встречал подготовленные без 
всякой автоматизации, вручную файлы с информацией об изменениях 
в версии, которая была критически важна для группы тестирования. 

Завершение цикла изменений — это последний этап итерационного 
процесса. При использовании автоматизированной системы управления 
дефектами и усовершенствованиями это обычно означает закрытие отче- 
тов о дефектах, для которых успешно завершилась проверка их устране- 
ния, повторное открытие и добавление комментариев в отчеты об ошиб- 
ках, которые оказались неисправленными, и подготовку новых отчетов о 
дефектах, обнаруженных при регрессионном тестировании, или об 
ошибках в новых функциях. (Более подробно о проверочном и регресси- 
онном тестировании и подготовке отчетов о дефектах рассказывается в 
главах 13 и 14.) Отчеты о повторно открытых ошибках и об ошибках рег- 
рессии, а также о новых ошибках, найденных в период планового тести- 
рования, передаются на следующий раунд управления содержимым вер- 
сий, исправления дефектов и документирования (см. рис. 12.2). 

До настоящего времени могло казаться, что в центре обсуждение сто- 
ит исходный код системы. Тем не менее я говорю обо всей системе, обо 
всех ее элементах. В ситуациях, когда данные и/или метаданные оказыва- 
ют существенное влияние на работу системы, проектная группа должна 
управлять этими элементами и документировать их так же тщательно, как 
и исполняемое содержимое. Например, как-то я работал в проекте, в ко- 
тором одна из групп разработки утверждала, что ее компонент системы 
содержит все свойства, но они перенесли изменения схемы базы данных 
для мастер-таблицы, которая содержала информацию о пользователях, 
из одной версии в следующую. Это вызвало столько же проблем при тес- 
тировании, как и добавление или удаление свойств, поскольку каждое 
поле было связано с изменениями пользовательского интерфейса и моди- 
фикациями сценариев использования системы и транзакций, которые 
оказывали влияние на агентов центра обработки вызовов. 
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Решение проблем 


Успешный процесс управления тестовыми версиями базируется на проч- 
ном фундаменте проверенных в течение десятилетий лучших способов 
организации работ по созданию систем. Тем не менее усложнение техно- 
логий и систем может действительно породить новые проблемы. Кроме 
того, возникают вопросы, связанные с управлением. Посмотрим на неко- 
торые из этих проблем. 


Кто отвечает за процессы подготовки тестовых версий? 


В таблице 12.1 представлены этапы процесса подготовки тестовых версий, 
описанного выше, и ответственные за каждый этап. В некоторых компани- 
ях этапы 3 — 6 живут где-то на необитаемом острове. Мне известны проекты, 
в которых ключевые участники, как мне кажется, полагали, что программы 
волшебным образом переходят от группы разработки к группе тестирова- 
ния без каких-либо затрат. Поскольку группа тестирования ожидает переда- 
чи программ, чтобы начать тестирование, часто эти этапы выполняются са- 
мой группой тестирования, которая не имеет ни сотрудников нужной 
квалификации, ни свободного времени на осуществление этого процесса 
без оказания влияния на эффективность и производительность группы. 


Таблица 12.1. Задачи процесса подготовки тестовых версий 
и ответственные за их выполнение 


Этап Задачи Ответственный 
(Как правило/Предлагается) 


1. Выбор содержимого новой версии Группа управления проектом, вклю- 


чающая в себя специалистов разных 
направлений 

2. Реализация изменений Группа разработки 

3. Сборка тестовой версии Неясно/Инженер сборок 


4. Приемочное тестирование тестовой Неясно/ Инженер сборок 
версии в среде управления конфигура- 


цией / сборкой 


5. Упаковка и передача тестовой версии Неясно/ Инженер сборок 
6. Установка тестовой версии в тестовой Неясно/Системные администраторы 
лаборатории (сложные системы) или группа тести- 
рования (простые системы) 
7. Приемочное тестирование тестовой Группа тестирования 


версии в тестовой лаборатории 


Когда процесс подготовки тестовых версий проходил гладко, за вы- 
полнение этапов 3 — 6 отвечали сотрудники в соответствии с предложе- 
ниями, представленными в таблице 12.11. Создание сборки, ее первое 
приемочное тестирование и передача тестовой версии находятся в сфере 
ответственности специально выделенного сотрудника рабочей группы 
проекта. Его называют по-разному, я буду использовать термин “инженер 
сборок” (геїсазе епріпеег). Кому он непосредственно подчиняется? Не ду- 
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маю, что это имеет значение. Я наблюдал, как группа тестирования под- 
чинялась группе обслуживания разработки, которая также отвечала за 
управление версиями (и пользовательскую документацию). Были случаи, 
когда инженер сборок являлся самостоятельной единицей группы разра- 
ботки. Оба подхода вполне работоспособны. 

Если не разрешается иметь в проектной группе специального инжене- 
ра сборок, выполнять такие обязанности в проектной группе должна 
группа разработки. Во всяком случае, при передаче каждой тестовой вер- 
сии менеджер разработки предлагает группе тестирования принять рабо- 
туего группы, поскольку она готова к тестированию. Разве не согласится 
менеджер разработки отвечать за задачи, связанные с передачей тестовой 
версии, если она готова к тестированию. 


Сложность системы, предназначенной для тестирования, 
и другие вопросы 


Как отмечалось выше, группе тестирования следует проверить процессы 
инсталляции, деинсталляции, установки обновлений и патчей и т.п. По- 
мимо этого, предметом анализа является сложность системы. Если вы 
тестируете приложение для ПК, его установка, скорее всего, является 
тривиальным процессом. Даже многие варианты ОС ОМІХ сейчас содер- 
жат дружественные, графические утилиты инсталляции. 

Предположим, однако, что мы начали добавлять дополнительные объ- 
екты, например базу данных, которая может быть как локальной, так и се- 
тевой. Что вы думаете по поводу трехзвенной архитектуры и о приложе- 
ниях на основе браузера, которые общаются с угеб-сервером, сервером 
приложений и сервером баз данных? Поскольку определение “системы, 
предназначенной для тестирования”, может быть расширено таким обра- 
зом, что оно начинает включать в себя разнообразные приложения, ино- 
гда выполняемые на различных аппаратных платформах и, возможно, 
взаимодействующие в различных сетевых архитектурах, сложность, при- 
сущая “установке системы”, будет увеличена от некоторого вполне охва- 
тываемого действия, выполняемого одним младшим тестировщиком, до 
задачи, требующей участия группы специалистов. Такая группа может 
быть очень специализированной и недешевой, чтобы тратить большую 
часть своего времени на тестирование; эти специалисты, по всей вероят- 
ности, работают в какой-то другой группе, например в группе сетевых 
операций или системного администрирования. 

Если учитывать всю совокупность проблем, которые встают перед груп- 
пой тестирования, такая сложность делает понятие состава “тестовой вер- 
сии” очень размытым, аморфным. Я работал в одном проекте, в котором 
тестовые версии содержали особые совокупности из одного или (обычно) 
многих приложений, которые были частями девяти отдельных подсистем. 
Над каждой из девяти подсистем трудилась отдельная группа разработки, 


Один из рецензентов, Маркус Манляйтнер (Магкиѕ Машейтег), отметил, что в случае 
сложного продукта приемочное тестирование версии в среде управления конфигурацией и 
сборками выполняется специальной комплексной группой тестирования. Он сообщил о не- 
плохих результатах при этом подходе. 
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и каждая подсистема имела номер версии, состоящий из пяти частей, на- 
пример 101.252.17.19.2003. Так что нужно было взять последовательность 
из 45 чисел, чтобы найти определенную тестовую версию. 

Более того, в этом проекте не существовало способа, при помощи ко- 
торого подсистема могла бы запросить номер другой подсистемы или пе- 
редать свой номер другой подсистеме, если та его запрашивала. Это суще- 
ственная проблема, поскольку подсистемы тесно связаны и по данным, 
и по потокам управления, проходящим через подсистемы и представлен- 
ным во многих тестовых сценариях. Тестировщик, вошедший в одну из 
подсистем, мог вовлекать в тестирование 3-4 другие подсистемы, но в луч- 
шем случае он мог запросить номер версии только у базовой подсистемы. 
В большинстве случаев подсистемы состояли из всевозможных приложе- 
ний, утилит, схем баз данных и других меняющихся компонентов. Однако 
приложение, которое видел тестировщик, не могло получить информа- 
цию о версиях других компонентов. 

Да, скажете вы, совершенно понятно, что иногда по-настоящему боль- 
шие, мультисистемные тестовые версии, подготовленные при участии 
нескольких групп, трудно поддаются управлению. Более мелкие и про- 
стые проекты не приводят к такого рода проблемам. 

Это не всегда верно. Я работал в проекте разработки Интернет- 
приложения, в котором у моего клиента было три различных программ- 
ных компонента: клиентское приложение, которое обеспечивало функ- 
ции браузера и почтового клиента, (встроенный) ВІОЅ для Интернет- 
приложения, версия встроенного программного обеспечения для моде- 
ма. У нас были устройства в тестовой лаборатории, причем когда мы их 
опрашивали, они показывали, что выполняют одни и те же программы, 
но это происходило потому, что мы не могли опросить модемы. Вышло 
так, что встроенные в модем программы менялись в процессе тестирова- 
ния изза внешних факторов, связанных с аппаратурой производителя 
модема. Эти изменения приводили к большому количеству проблем со- 
единения в определенных версиях встроенных программ. Можете пред- 
ставить, насколько нас сбивали с толку попытки локализовать проблемы 
надежности в коммутируемых сетях в очевидно одинаковых конфигура- 
циях системы, которые на самом деле не были одинаковыми. 

Мне неизвестны технические решения, которые могут работать с не- 
сравнимыми, произвольно большими и сложными системами тестов. Од- 
нако проблемы, упомянутые выше, являются не только техническими. 
Это вопросы дисциплины управления изменениями. Почему производи- 
тель модема изменял встроенные программы, не уведомляя нас? Потому 
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что группа управления проектом не сообщила ему, что он должен это де- 
лать. Почему программисты, создавая различные подсистемы, не создали 
простые утилиты для опроса центральной базы данных, чтобы опреде- 
лять версию системы, всех ее 45 сегментов? Потому что руководство не 
сообщило им, что они должны это делать. В обоих случаях группа управ- 
ления изменениями, функционирующая надлежащим образом, могла бы 
решить эти проблемы с привлечением простых, но надежных методов 
создания и запроса версий. Как и в случае с информацией об изменениях 
в версии, отсутствие готовых программных средств, позволяющих ре- 
шать проблему автоматически, не отменяет ответственности рабочей 
группы проекта за решение проблемы. 

Проблемы тестовой версии вытекают и из сложности тестовой среды. 
Повторю, важно знать, что мы тестируем, и это касается программных и 
аппаратных средств, в окружении которых работает система, предназна- 
ченная для тестирования. Однако в отличие от тестируемой системы тес- 
товая среда либо меняется незначительно, либо вообще не меняется в 
ходе проекта тестирования. Если в тестируємой системе мы пытаемся до- 
биться упорядоченных и управляемых изменений, то в тестовой среде мы 
хотим избежать изменений настолько, насколько это возможно. Единст- 
венным исключением, я думаю, являются необходимость изменения оп- 
ределения развернутой среды и необходимость тестирования различных 
конфигураций в случае, когда система будет работать в большом числе ва- 
риантов среды поставки или среды пользователей. 

Доступность инструментов управления конфигурацией системы, пред- 
назначенной для тестирования, и конфигурацией тестовой среды сущест- 
венно зависит от целевой платформы. Міпӣоиѕ и СМІХ, включая Ипих, об- 
ладают довольно широким ассортиментом таких инструментов, в то время 
как другие, менее применяемые платформы, возможно, не имеют таких 
средств. Заметим также, что подходящий набор инструментов для этой ра- 
боты зависит не только от целевой платформы, но и от предполагаемого 
процесса установки. В некоторый момент группе проекта, вероятно, по- 
требуется протестировать процессы инсталляции, деинсталляции, уста- 
новки обновлений и патчей, Некоторые простые методы управления кон- 
фигурацией системы тестов могут подорвать близость тестовой среды 
к реальной и сделать недействительными результаты тестирования. 


Неполные и нереалистичные тестовые версии для системного 
тестирования и приемо-сдаточных испытаний 


В ходе ранних фаз тестирования (модульного, компонентного и ком- 
плексного тестирования) тестировщики (программисты, независимые 
тестировщики или кто-то другой) обычно получают тестовые версии, ко- 
торые не являются полными, содержат заглушки, драйверы или еще 
какие-либо отличия от той версии, которая будет передана заказчику. Со- 
гласно эволюционной и итерационной методологиям каждая из версий, 
предоставляемая на системное тестирование, также не будет содержать 
все свойства версии, передаваемой заказчику. Даже в рамках жизненного 
цикла каскадной и У-модели существуют формальные и неформальные 
основания для изменения определения системы, передаваемой на сис- 
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темное тестирование. Формальными основаниями могут быть решения 
группы управления изменениями, неформальными основаниями могут 
быть просьбы или угрозы со стороны программистов или руководства от- 
срочить реализацию любимых свойств. 

Однако, как отмечала Лин Цу в нашем примере, тестирование непол- 
ных и нереалистичных тестовых версий в ходе последних циклов тести- 
рования неизбежно является рискованным. Такая ситуация создает веро- 
ятность пропуска проблем с регрессией и скрытых дефектов. 

Кроме того, что такое исправление дефекта, как не небольшое измене- 
ние в определении системы? Следовательно, если мы исправляем ошиб- 
ки, мы меняем систему точно так же, какесли бы мы добавили новые свой- 
ства. До определенной степени изменение кода может стать объектом 
риска независимо от того, добавляем ли мы новые свойства или просто 
исправляем ошибки. Это вторжение в код порождает риск постольку, по- 
скольку такова природа изменения . 

Другая проблема - отсутствие реализма. Отсутствие реализма может 
иметь следующее проявление. Передается и инсталлируется тестовая 
версия, которая подрывает наши возможности протестировать процес- 
сы лицензирования, выпуска, передачи и установки так, как они проис- 
ходят в реальном мире. Сама система также может оказаться не совсем 
реальной. Например, мы применяем средство покрытия кода для инст- 
рументирования исходного кода, а затем создаем и выполняем систем- 
ные тестовые сценарии на инструментированной системе. Такое тести- 
рование может предоставить полезную информацию, касающуюся 
структурного тестирования, но какова вероятность того, что инстру- 
ментирование оказало влияние на результаты тестирования? Это может 
произойти, если мы используем инструментированные системы тестов 
для тестирования мощности, объема, перегрузок и производительно- 
сти, поскольку инструментирование увеличивает размер и уменьшаєт 
производительность системы, за исключением некоторого небольшого 
процента случаев, когда мы используем хорошие средства инструменти- 
рования. 

Основной прием решения этих проблем — поиск компромисса между 
преимуществами и риском. В ходе начальных фаз тестирования и даже во 
время системного тестирования вы не ожидаете, что группа проекта пре- 
кратит внесение изменений в код, поскольку при помощи изменений до- 
бавляются свойства и улучшается качество. На рынке с высокой конку- 
ренцией удовлетворение спроса на новейшие свойства и технологии 
может стать стратегической целью, и будет нелогично, если наше жела- 
ние иметь надежную тестовую среду помешает целям бизнеса. Однако 
иногда риск изменений угрожает другой цели бизнеса: передаче или по- 
ставке качественной системы. 


Некоторые используют процент нового и измененного кода в репозитории кода в каче 
стве метрики для завершения системного тестирования. Эта метрика может дать вам пред 
ставление о вероятности регрессии или новых дефектов. Поскольку хочется, чтобы к концу 
проекта ежедневное число дефектов стремилось к нулю, соответственно есть желание, что- 
бы процент изменений кода также стремился к нулю. Кроме того, чем меньше изменяется 
код, тем более значимыми со временем становятся результаты тестирования. Если 10% кода 
меняется каждую неделю, о чем скажут результаты тестирования 5-6 недельной давности? 
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Прозорливый тест-менеджер может оказать помощь группе проекта 
в уравновешивании этих рисков. Рассмотрим пример. В проекте разра- 
ботки Интернет-приложения, следовавшем жизненному циклу разработ- 
ки У-модели, один из критериев начала системного тестирования гласил, 
что система должна иметь все запланированные свойства перед началом 
системного тестирования. На совещании, где принималось решение о на- 
чале системного тестирования, мы отказались от этого критерия в отно- 
шении двух конкретных свойств: печати и поддержки свойств аудио. Про- 
граммисты все еще продолжали над ними работать, поскольку эти 
свойства считались важными для первой версии. Тем не менее имело 
смысл начать системное тестирование. С одной стороны, большая часть 
системы была завершена, и мы действительно получали на тестирования 
систему, хотя и не финальную ее версию. С другой стороны, существовала 
вероятность, что технические проблемы могут воспрепятствовать завер- 
шению работы над этими свойствами, поэтому задержка системного тес- 
тирования в ожидании реализации этих свойств могла бы поставить под 
угрозу дату поставки системы, причем указанные свойства могли все рав- 
но не войти в первоначальную поставку. Мы были связаны только крите- 
рием завершения тестирования, который предполагал трехнедельное 
тестирование без изменений, за исключением исправления дефектов, 
имеющих незначительный риск. 

До некоторой степени мы можем снизить риск появления нереали- 
стичных версий на системном тестировании, используя стратегию рег- 
рессионного тестирования. Если мы повторяем тесты в соответствии со 
стратегией регрессионного тестирования (см. главу 13), мы можем допус- 
тить инструментированные тестовые версии и значительные изменения, 
пока не начнем заключительный полный прогон всех тестов. (Конечно, 
здесь существует риск, что мы обнаружим регрессию или скрытые про- 
блемы при последнем прогоне, что может угрожать срокам, но это мень- 
ший риск, чем не обнаружить проблем вовсе.) Если вы совсем не повто- 
ряете тесты, то любой прогон тестов для инструментированной или 
устаревшей тестовой версии повышает риск обнаружения регрессии или 
скрытых ошибок в заключительной версии. 


Внедрение усовершенствований 


Процесс подготовки тестовых версий — это один из наиболее чувстви- 
тельных к контексту процессов. Общий процесс, описанный выше, дает 
хорошие результаты во многих случаях, но не во всех. Особые техноло- 
гии и инструменты, на которых базируется процесс, оказывают большое 
влияние на то, как он осуществляется. Они также определяют точки при- 
ложения усилий, которые позволяют получить возврат вложений в изме- 
нение процесса. Однако я обнаружил несколько общих правил, заслужи- 
вающих внимания. 


1. Подумайте о преимуществах инсталлируемых средств, надежного 
автоматизированного модульного, компонентного и комплексного 
тестирования каждой тестовой версии и приемочного тестирова- 
ния для эффективности проекта тестирования. 
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2. Рассмотрите увеличение эффективности проекта, которое может 
быть получено за счет наличия средств именования версий и их за- 
проса. Неспособность понять, в какой версии есть ошибка, рас- 
страивает не только разработчиков, но и тестировщиков, посколь- 
ку программисты отмечают ошибки как невоспроизводимые, когда 
проблема состоит в том, что никто не знает, что происходило в тес- 
товой лаборатории во время тестирования. На уровне управления 
тестированием может произойти существенная потеря доверия 
группе тестирования, если разработчики не могут найти пробле- 
мы, о которых сообщают тестировщики. Позор, если причиной 
этого являются коммуникативные проблемы, когда группа тестиро- 
вания не в состоянии правильно назвать объект тестирования. 


3. Посмотрите на источники снижения эффективности в процес- 
сах выполнения тестов и подготовки отчетов о дефектах. Я видел 
много проектов, которые попусту теряли две и более недели в на- 
чале тестирования, поскольку никто не понимал, как установить 
тестовую версию так, чтобы она работала. Я также сталкивался с 
проектами, которые превращались в бесконечную цепь ошибок, 
блокированного тестирования и несовместимых компонентов, 
сталкивающихся в тестовой лаборатории. 


С передачей хороших тестовых версий не только улучшается процесс 
тестирования, но и вы становитесь более производительными. Я отстаи- 
ваю идею простых процессов именования и запроса номеров версий, ар- 
гументируя это улучшением предоставления услуг группе разработки. 
Иногда я говорю: “Профессиональная группа тестирования должна пи- 
сать хорошие отчеты об ошибках; мы хотим точно указать, в каких верси- 
ях есть конкретные ошибки. Чтобы это можно было сделать достаточно 
надежно, мы обращаемся к вам за помощью в разработке качественных 
процессов именования и запроса имен версий”. Что касается провероч- 
ного тестирования, я обычно говорю, что мы можем лучше и быстрее 
проверить, можно ли закрывать ошибки, если мы точно знаем, в какой 
версии они возникли. 

Хорошие тестовые версии указывают на зрелость процесса и позволя- 
ют сэкономить время группы тестирования, что идет на пользу проекту. 
Во всех проектах, в которых я участвовал, а их было около десятка, и кото- 
рые, по моему мнению, действительно отменно управлялись, былхорошо 
поставлен процесс подготовки тестовых версий. Три проекта, которые 
я вспоминаю как наиболее проблемные, испытывали трудности именно 
с управлением процессом подготовки тестовых версий. Невозможно ус- 
пешно проводить тестирование без качественной подготовки тестовых 
версий, а невозможность успешного проведения тестирования обычно 
рассматривается как ключевой фактор неудачи проектов. 

Помимо эффективности и успеха проекта, другим фактором, способст- 
вующим качественной подготовке тестовых версий, является неотврати- 
мость передачи результатов проекта. Рано или поздно проектная группа 
должна передать инсталлируемую и стабильную версию пользователям 
или заказчикам. Рано или поздно проектная группа должна подготовить 
работоспособные процессы инсталляции, деинсталляции, установки об- 
новлений и патчей для версий заказчиков и пользователей. Рано или позд- 


Глава 12, Передача материалов 361 


но система получит номер версии, а заказчики и пользователи должны бу- 
дут иметь возможность сообщать номер версии, если они обнаружат 
проблемы. Рано или поздно нужно будет согласовать все компоненты сис- 
темы и установить все взаимодействующие компоненты в рабочую среду. 
Поскольку рано или поздно должны быть решены все вопросы, рассмот- 
ренные в этой главе, почему не начать получать эти решения и проверять 
их в ходе тестирования? 

Поскольку изменения неизбежны, их появление — это только вопрос 
времени. Если кто-то настаивает на том, чтобы отложить определение 
и формирование качественных процессов подготовки версии до конца 
проекта, воспользуйтесь вашими контактами с группами обслуживания 
пользователей, технической поддержки, системы сетевой поддержки и 
с бизнес-аналитиками из проектной группы, чтобы они помогли убедить 
руководство в необходимости изменений. Могут также помочь и сотруд- 
ники отделов продаж и маркетинга. Если до людей, которые тесно обща- 
ются с заказчиком и знают пользователей, удастся донести значение про- 
цессов подготовки версий, то их можно убедить поддержать ваши 
призывы следовать процессу подготовки тестовых версий, который 
раньше вскроет потенциальные проблемы. 

Как только мне удается убедить людей в необходимости изменений, 
обычно я даю возможность разработчикам и инженерам сборки руково- 
дить определением деталей процесса подготовки версий. Меня не сильно 
волнуют все эти подробности, поскольку сам процесс отвечает критери- 
ям и решает проблемы, описанные в этой главе. Я рад работать с людьми 
и помогать им в формировании качественного процесса. Суть процесса 
все-таки в передаче результатов. В эстафете бегуны должны согласовы- 
вать момент передачи эстафетной палочки, поскольку неудачная переда- 
ча означает ее падение и поражение в соревнованиях. Придерживайтесь 
этого сравнения при передаче результатов, и вы сможете добиться много- 
го, когда наступит время внедрять изменения в процессы подготовки тес- 
товых версий. 


ГЛАВА 13 


Оценка качества: выполнение 
тестовых сценариев 


Н аконец, пришло время тестирования. В ходе выполнения тестов 
тестировщики используют ту систему тестов, которую мы подгото- 
вили для оценки качества тестовых версий, по мере того, как мы их полу- 
чаем. Это, с одной стороны, волнующий, а с другой стороны, страшащий 
момент проекта, поскольку качество системы неизвестно, пока тестиров- 
щики не начали работать с ней. Более того, группа тестирования обычно 
имеет здесь уникальную возможность поиска способов заставить систему, 
предназначенную для тестирования, выйти, насколько это возможно, из- 
под контроля и за рамки ожидаемого поведения. 

Кроме того, хотя от всех руководителей ожидают управления непред- 
сказуемыми событиями в рамках их сфер ответственности, тест-менед- 
жер — это единственный руководитель в компании, чьей сферой ответст- 
венности является поиск непредсказуемых событий. Этот поиск 
принимает форму выполнения комплекта тестов. Каким образом группа 
тестирования выбирает тесты, выполняет их в установленной системе и 
собирает информацию о системе, предназначенной для тестирования, о 
тестовых сценариях и о самом процессе выполнения тестов? 


Процесс выполнения тестов 


Начнем с общего процесса выполнения тестов — Процесса 9. Этот про- 
цесс пересекается с другими процессами. Этап 3.0, подготовка отчетов о 
проблемах качества тестируемой системы, следует процессу, описанному 
в главе 14. Этап 3.Е, устранение проблем в системе тестов, следует процес- 
су, представленному в главах 10 и 11. Наконец, этап 7, отчет о результатах 
тестового цикла и ходе тестирования, подчиняется процессу, обсуждае- 
мому в главе 151. 


Я благодарен Тиму Коомену (Тип Коотеп) за то, что он напомнил мне о некоторых эле- 
ментах управления конфигурацией тестирования в этом процессе. 
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Процесс 9. Процесс выполнения тестов 


№ этапа Этап Выполнено? 


1. На основе приоритетов рисков, ограничений проекта и дру- о 
гих соображений выбрать комплекты тестов (из всего множе- 
ства тестов), которые должны быть выполнены в данном тес- 
товом цикле. 


2. Назначить тестировщиков, ответственных за выполнение тес- п 
товых сценариев из каждого комплекта тестов. 
3. Выполнить тестовые сценарии, подготовить отчеты о дефек- О 


тах и непрерывно собирать информацию о тестах, принимая 
во внимание при выполнении очередного теста предыдущие 


результаты тестирования. 


ЗА Привести систему, предназначенную для тестирования, и сис- О 
тему тестов в соответствующие исходные состояния. Если 
данные исходные состояния понадобятся для выполнения 
различных тестов или нескольких итераций данного теста, со- 


хранить исходные состояния для последующего применения. 


3.В При помощи ввода данных и других действий заставить систе- О 
му, предназначенную для тестирования, реагировать на же- 


лаемые тестовые условия. 


3.С Наблюдать и оценивать выходные данные, поведение систе- О 
мы и ее состояния. Исследовать любые отклонения от ожи- 


даемых результатов. 


3.р Если необходимо, подготовить отчеты о проблемах в системе, О 
предназначенной для тестирования. 

ЗЕ Если необходимо, подготовить отчеть о проблемах в системе О 
тестов и/или исправить их. 

З.Р Собрать информацию и подготовить отчет о выполненных О 
тестах. 

4. Решать проблемы, препятствующие тестированию, при их О 
возникновении. 

5. Ежедневно готовить отчет о ходе тестирования, уточнять от- О 


ветственных за выполнение тестов и пересматривать планы 
и приоритеты. 


6. Если необходимо, удалить невыполнимые или устаревшие тес- п 
ты в порядке, обратном их приоритетности (сначала удалять 


тесты низших приоритетов, в последнюю очередь і высших). 


7. Периодически отчитываться о ходе и результатах тестового О 
цикла. 
8. Поместить все документы о ходе работ, начальные состояния, п 


обновленнье средства тестирования, другие элементы систе- 


мы тестов и прочую информацию, получаемую на постоянной 
основе, в проектную библиотеку или систему управления кон- 


фиг урациями. Вести контроль изменений всех элементов. 
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Таблицы отслеживания тестов 


В этой главе рассказывается о планировании и отслеживании выполне- 
ния тестов при помощи таблицы, которую я называю таблицей отслежи- 
вания тестов”. Основными частями этой таблицы являются сводная таб- 
лица тестовых сценариев и сводная таблица комплектов тестов. 

На рис. 13.1 показана сводная таблица тестовых сценариев в том виде, 
в каком она появилась в начале раунда 5, после того как тест-менеджер 
Джамал Браун завершил отбор комплектов тестов и назначил тестиров- 
щиков, ответственных за выполнение каждого сценария. В столбце “От- 
ветственный” указывается отвечающий за выполнение тестировщик. 
Столбец “Номер теста” содержит уникальный четырехзначный номер ка- 
ждого теста. Столбец "Комплект тестов/Тестовый сценарий” содержит 
краткое наименование каждого комплекта тестов и каждого тестового 
сценария. Столбец “Плановая дата” содержит информацию о дате плано- 
вого завершения теста согласно ожиданиям Джамала. Столбец “Плано- 
вые затраты” указывает число человеко-часов, необходимых, по оценке 
Джамала, на выполнение каждого тестового сценария. 

По мере того как тестировщики будут выполнять каждый тест, они бу- 
дут собирать информацию о тестах. Один из наиболее существенных эле- 
ментов информации -- состояние теста. 


и На очереди. Тестовый сценарий готов к выполнению, назначен тес- 
тировщик, отвечающий за его выполнение в этом раунде. 


и В работе. Тест выполняется в настоящее время. 
ш Заблокирован. Что-то мешает тестировщику выполнить тест. 


ОЕ 


ріж 


Моей хан Свати 


Рис. 131. Таблица тестовых сценариев на момент начала раунда 5 


1 Подробное описание этого инструмента приведено в главе 5 моей предыдущей книги 
“Малавтр ше Теятр Ргосеѕѕ, 5есопа Е@ ют’. 
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и Пропущен. По некоторой причине тестировщик решил не выпол- 
нять тест. 


и Прошел. Тестировщик выполнил тест целиком и наблюдал только 
ожидаемые результаты, состояния и поведение. 


ш Не прошел. Тестировщик выполнил тест целиком и наблюдал один 
или более непредусмотренных результатов, состояний или поведе- 
ние, серьезно подвергающее риску качество системы в отношении 
цели теста. 


ш Предупреждение. Тестировщик выполнил тест целиком и наблюдал 
один или более непредусмотренных результатов, состояний или 
поведение, однако качество системы в отношении цели теста не 
подвергается серьезному риску. 


и Закрыт. После того как в предыдущем раунде тестового цикла 
тест был помечен как “Не прошел” или “Предупреждение”, в сле- 
дующей тестовой версии содержится исправление ошибки, кото- 
рое реша | 


В ходе выполнения всех запланированных тестовых сценариев для 
тестового раунда тестировщики проходят по жизненному циклу тестов, 
показанному на рис. 13.2. 

Помимо состояния тестового сценария, тестировщики собирают дру- 
гую важную информацию. В столбце “Тестовая среда” (см. рис. 13.1) они 
указывают, какое аппаратное и программное обеспечение и другие эле- 
менты используются для выполнения теста. В столбцах “Номер дефекта” 
и “Приоритет дефекта” размещается информация об обнаруженных де- 
фектах (см. главу 14). В столбце “Кем выполнен” каждый тестировщик 


Рай Заблокирован | чо, Ж (=) 
і М 
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М 
М 
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На очереди кун ненні В работе 
/ / 
/ ГА 
Гай СА 
й ГА 
Ра 2 
5) чапро й 


Рис. 13.2. Состояния и жизненный цикл тестовых сценариев 


Некоторые применяют более простые множества состояний тестов. Например, Джоан- 
на Ротман рассказала мне, что она не применяет статусы “Заблокирован”, “Предупрежде- 
ние” и “Закрыт”, а использует “Не прошел”, “В работе” и “Прошел” соответственно. 
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Таблицы отслеживания тестов 


В этой главе рассказывается о планировании и отслеживании выполне- 
ния тестов при помощи таблицы, которую я называю таблицей отслежи- 
вания тестов . Основными частями этой таблицы являются сводная таб- 
лица тестовых сценариев и сводная таблица комплектов тестов. 

Нарис. 13.1 показана сводная таблица тестовых сценариев в том виде, 
в каком она появилась в начале раунда 5, после того как тест-менеджер 
Джамал Браун завершил отбор комплектов тестов и назначил тестиров- 
щиков, ответственных за выполнение каждого сценария. В столбце “От- 
ветственный” указывается отвечающий за выполнение тестировщик. 
Столбец “Номер теста” содержит уникальный четырехзначный номер ка- 
ждого теста. Столбец “Комплект тестов/Тестовый сценарий” содержит 
краткое наименование каждого комплекта тестов и каждого тестового 
сценария. Столбец “Плановая дата” содержит информацию о дате плано- 
вого завершения теста согласно ожиданиям Джамала. Столбец “Плано- 
вые затраты” указывает число человеко-часов, необходимых, по оценке 
Джамала, на выполнение каждого тестового сценария. 

По мере того как тестировщики будут выполнять каждый тест, они бу- 
дут собирать информацию о тестах. Один из наиболее существенных зле- 
ментов информации -— состояние теста. 


и На очереди. Тестовый сценарий готов к выполнению, назначен тес- 
тировщик, отвечающий за его выполнение в этом раунде. 


и В работе. Тест выполняется в настоящее время. 
и Заблокирован. Что-то мешает тестировщику выполнить тест. 


Фихгабоді Соли А 


Рис. 131. Таблица тестовых сценариев на момент начала раунда 5 


1 Подробное описание этого инструмента приведено в главе 5 моей предыдущей книги 
"Мапаріпр йе Теѕйпо Ртосеѕэ, Зесопа Её ют”. 
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и Пропущен. По некоторой причине тестировщик решил не выпол- 
нять тест. 


„м Прошел. Тестировщик выполнил тест целиком и наблюдал только 
ожидаемые результаты, состояния и поведение. 


м Не прошел. Тестировщик выполнил тест целиком и наблюдал один 
или более непредусмотренных результатов, состояний или поведе- 
ние, серьезно подвергающее риску качество системы в отношении 
цели теста. 


ш Предупреждение. Тестировщик выполнил тест целиком и наблюдал 
один или более непредусмотренных результатов, состояний или 
поведение, однако качество системы в отношении цели теста не 
подвергается серьезному риску. 


и Закрыт. После того как в предыдущем раунде тестового цикла 
тест был помечен как “Не прошел” или “Предупреждение”, в сле- 
дующей тестовой версии содержится исправление ошибки, кото- 
рое реша 


В ходе выполнения всех запланированных тестовых сценариев для 
тестового раунда тестировщики проходят по жизненному циклу тестов, 
показанному на рис. 13.2. 

Помимо состояния тестового сценария, тестировщики собирают дру- 
гую важную информацию. В столбце “Тестовая среда” (см. рис. 13.1) они 
указывают, какое аппаратное и программное обеспечение и другие эле- 
менты используются для выполнения теста. В столбцах “Номер дефекта” 
и “Приоритет дефекта” размещается информация об обнаруженных де- 
фектах (см. главу 14). В столбце “Кем выполнен” каждый тестировщик 
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Рис. 13.2. Состояния и жизненный цикл тестовых сценариев 


Некоторые применяют более простые множества состояний тестов. Например, Джоан- 
на Ротман рассказала мне, что она не применяет статусы “Заблокирован”, “Предупрежде- 
ние” и “Закрыт”, а использует “Не прошел”, “В работе” и “Прошел” соответственно. 
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вводит свои инициалы. “Дата выполнения” указывает, когда тестиров- 
щик выполнил тестовый сценарий, “Фактические затраты” показывают, 
сколько человеко-часов было потрачено тестировщиком, а “Продолжи- 
тельность выполнения теста” показывает астрономическое время выпол- 
нения теста. (Продолжительность выполнения теста и затраты на выпол- 
нение могут отличаться для автоматизированных и ручных тестов, 
которые выполняются несколькими тестировщиками.) 

Чтобы лучше понимать, что происходит со всеми комплектами тес- 
тов, и собирать полезную информацию для измерений (см. главу 15), 
я провожу анализ информации о состоянии теста и затратах на его выпол- 
нение в сводной таблице комплектов тестов, как показано на рис. 13.3. 
Это таблица содержит информацию о каждом комплекте тестов и по все- 
му множеству тестов. К. классу выполненных тестов я отношу те тесты, ко- 
торые проведены или пропущены. (Для простоты тесты в состояниях 
“Предупреждение” и “Закрыт” я регистрирую в столбце “Прошел”.) Я от- 
ношу кклассу невыполненныхте тесты, которые заблокированы или еще не 
завершены. Эта классификация позволяет мне проанализировать, в ка- 
кой точке процесса проведения тестов я нахожусь. 

Раздел “Выполненная работа” с правой стороны позволяет проанали- 
зировать, прошли ли мы нужное количество тестов в каждом комплекте, с 
учетом фактических затрат. Например, если мы прогнали 7 из 14 тесто- 
вых сценариев, мы выполнили 50% тестов (эта цифра появляется в столб- 
це “Процент выполнения”). Предположим, что мы израсходовали 
40 человеко-часов из 50 запланированных. В этом случае мы потратили 
80% запланированных затрат (указывается в столбце “Процент затрат”). 
Это означает, что мы вряд ли завершим оставшиеся 7 тестов в запланиро- 
ванные сроки (считая, что все тестовые сценарии примерно одного раз- 
мера, и не принимая в расчет вопросы приоритетности). Если это проис- 
ходит со всеми комплектами тестов, то мы выйдем за рамки времени, 
отведенного на выполнение тестов, до того, как завершим все тесты, за- 


Рис. 13.3. Таблица комплектов тестов на момент начала раунда 5 


368 


Часть Ш. Проведение 


мость позволяет тест-менеджеру или ведущему тестировщику вовремя 
скорректировать план тестового раунда. 


Атака на большую сборку 


В качестве первоначального действия каждую неделю группа тестирова- 
ния “Суматры” выполняла проверочное тестирование исправлений де- 
фектов в новых тестовых версиях согласно плану тестирования. В случае 
с большой сборкой оказалось много ошибок для верификации исправле- 
ний. Пока группа тестирования занималась проверочным тестировани- 
ем, Джамал подробно планировал работу на предстоящую неделю. 

Поскольку на тестирование был передан инкремент 3, это означало, 
что на этой неделе во внешних тестовых лабораториях должен начаться 
первый раунд тестирования локализации и удобства использования. Джа- 
мал еще раньше попросил Лин Цу координировать эти действия с тесто- 
выми лабораториями и сделал пометку о необходимости напомнить ей об 
этом ближе к делу. Во вторник она связалась с лабораториями и заплани- 
ровала передачу тестовой версии в обе лаборатории на вторую половину 
дня понедельника. В результате она получила запас времени для того, что- 
бы убедиться, что тестовая версия готова к началу тестирования. 

Большая сборка означала большую работу. Это понимал Джамал, глядя 
натаблицу отслеживания тестовых сценариев. В ходе этого раунда он пла- 
нировал пропустить только один комплект тестов — комплект для провер- 
ки надежности и стабильности. Это означало, что Эмма Мурхаус, одна из 
инженеров по автоматизации тестирования, будет выполнять комплект 
для тестирования производительности, нагрузки, мощности и объема, 
что требовало больших затрат. 

Определенную проблему создавал и тот факт, что в середине тестово- 
го цикла были Рождественские каникулы. Однако Джамал пригласил в 
группу тестирования людей, относящихся к разным культурам, что по- 
зволяло избежать полной потери недельного периода. Он уже догово- 
рился о том, что инженер по ручному тестированию Лин Цу Ву и один из 
младших тестировщиков Джон Ву будут отдыхать в начале следующего 
года во время празднования китайского нового года по лунному календа- 
рю вместо рождества. Инженер по автоматизированному тестированию 
Динеш Кумар и младший тестировщик Эмамалини Шашидар получат до- 
полнительную неделю к двухнедельному отпуску в апреле, после выпус- 
ка версии, чтобы посетить свои семьи в Индии и Бангладеш. Биньямин 
Цукерман поедет навестить семью в Нью-Йорк во время хануки. Таким 
образом, каждый тестировщик сможет хорошо провести свои религиоз- 
ные и культурные праздники, а Джамал сможет распределить влияние 
этих праздников по нескольким раундам тестирования. Таким образом, 
на Рождественской неделе будут работать пятеро из семи его тестиров- 
щиков. 

Джамал взглянул на распределение тестовых сценариев, которые 
должны быть выполнены в наступающем тестовом цикле на этой неделе. 
В первую очередь, с точки зрения рисков, нужно выполнить тесты, кото- 
рые были ранее заблокированы, особенно функциональные. Некоторые 
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из сделанных изменений означают, что также важно выполнить тесты, 
проверяющие секретность, безопасность и обработку ошибок. 


№ этапа Этап Выполнено? 


1. На основе приоритетов рисков, ограничений проекта и дру- М 
гих соображений выбрать комплекты тестов (из всего множе- 
ства тестов), которые должны быть выполнены в данном тес- 
товом цикле. 


Джамал просмотрел каждый комплект тестов и, исходя из приоритет- 
ности рисков, определил плановые даты завершения и назначил тести- 
ровщиков, отвечающих за каждый тестовый сценарий. На основе преды- 
дущих раундов он также пересмотрел плановые часы для каждого 
тестового сценария. Часть полученной им в качестве плана таблицы от- 
слеживания тестовых сценариев показана на рис. 13.1. 


№ этапа Этап Выполнено? 


2. Назначить тестировщиков, ответственных за выполнение тес- М 
товых сценариев из каждого комплекта тестов. 


После распределения ответственных Джамал подготовил семь копий 
этой таблицы для раунда 5. Чувствуя, что на очереди совещание по син- 
хронизации работы группы, изная, что ничто такне способствует удачно- 
му совещанию, как хорошая пища, он отправил группе тестирования со- 
общение по электронной почте. 


Привет всем! 


Пришла большая сборка. Наступило время для наиболее важного и сложного 
тестового цикла в проекте. Чтобы убедиться, что мы все работаем син- 
хронно, пожалуйста, соберитесь в полдень в тестовой лаборатории для 
обеда, посвященного началу тестового цикла. Я выдам каждому таблицу от- 
слеживания тестовых сценариев с распределением ответственных за выпол- 
нение тестовых сценариев, плановыми часами и плановыми датами заверше-: 
ния этого цикла. Чтобы никто не опаздывал, я закажу обед в нашем 
любимом индийском ресторане с обычными неострым, вегетарианским и ко- 
шерным вариантами. Помните, те, кто обожает ядреную острую куриную вин- 
далу и аачар так же, как Эмма и я, должны не опаздывать, иначе мы съе- 
дим все! 


С уважением, 


Джамал 


Совещание прошло успешно. Необходимо было выполнить много ра- 
боты за короткое время, но благодаря планированию каникул, проведен- 
ному загодя Джамалом, загрузка не была чрезмерной, даже с учетом Рож- 
дественских праздников. Возможно, более важным было то, что каждый 
тестировщик горел желанием заняться тестированием большой сборки, 
тестовой версии с (почти) полным набором свойств. Как сказал один из` 
младших тестировщиков, Луис Хасинто: “Наконец-то полная кружка Су- 
матры, а не малюсенькие чашечки для эспрессо”. 
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“Итак, — сказал Джамал, когда совещание и еда на столах подошли 
к концу, — отправляйтесь и найдите много ошибок. Я знаю, они прячутся 
в большой сборке. Встречусь с вами для разбора полетов во время пере- 
сменки в 16.00”. 

Тестировщики отправились выполнять тесты. Луис Хасинто начал 
свою работу с функционального теста для управляемых файлов. Настрой- 
ка этого тестового сценария требовала запуска нового экземпляра 
рееду\М/тгиег на клиентской тестовой машине, а затем регистрации в сис- 
теме управления документооборотом. Первый этап теста включал в себя 
создание нового файла, ввода в него некоторого текста и помещения фай- 
ла в систему управления документооборотом. 


№ этапа Этап Выполнено? 


ЗА Привести систему, предназначенную для тестирования, и сис- М 
тему тестов в соответствующие исходные состояния. Если 
данные исходные состояния понадобятся для выполнения 
различных тестов или нескольких итераций данного теста, со- 
хранить исходные состояния для последующего применения. 


3.В При помощи ввода данных и других действий заставить систе- М 
му, предназначенную для тестирования, реагировать на же- 
лаемые тестовые условия. 


Здесь Луис обнаружил, что функция создания файла серьезно наруше- 
на. Изза этого повреждались все новые файлы, когда производились оп- 
ределенные действия над шрифтами. Он выяснил, что существует единст- 
венный обходной путь — поместить файл в систему документооборота 
сразу после создания, не начиная редактировать его. Помимо выполне- 
ния плановых тестов, Луис потратил некоторое время на исследование и 
подготовку отчета о дефекте. Это заняло немногим больше времени, чем 
запланированные два с половиной часа, но ему нужно было время на лока- 
лизацию и документирование столь критической ошибки. Перед тем как 
начать выполнение следующего тестового сценария, он пометил каранда- 
шом информацию о состоянии тестового сценария в таблице отслежива- 
ния тестовых сценариев. 


№ этапа Этап Выполнено? 
3.С Наблюдать и оценивать выходные данные, поведение систе- 
мы и ее состояния. Исследовать любые отклонения от ожи- 
даемых результатов. 
3.0 Если необходимо, подготовить отчеты о проблемах в системе, М 
предназначенной для тестирования. 
З.Е Собрать информацию и подготовить отчет о выполненных 
тестах. 


Затем Луис перешел к выполнению теста для неуправляемых файлов. 
Но вэто время системный администратор по неосторожности отключил 
Тобрук — меЪ- сервер на іпих, которым пользовался Луис. После некото- 
рого недоумения он обнаружил, что сервер перезагружен, однако было 
потеряно около часа. 
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№ этапа Этап Выполнено? 
4. Решать проблемы, препятствующие тестированию, при их Я 
возникновении. 


После ежедневного подведения итогов с участием всей группы тести- 
рования Луис провел еще пару часов за тестированием, затем в течение 
часа читал электронную почту и отвечал на письма, пока не завершился 
его 10-часовой рабочий день. Еще несколько минут он обсуждал ошибку, 
связанную со шрифтами, с Бинямином Цукерманом, одним из младших 
тестировщиков вечерней смены. В соответствии с таблицей отслежива- 
ния тестовых сценариев, сегодня вечером Бинямин назначен ответствен- 
ным за тестирование шрифтов. Они также немного поговорили о скорой 
поездке Бинямина в Нью-Йорк, в частности о его планах посмотреть на 
реконструкцию в Нижнем Манхеттене. Наконец Луис отправился на 
поздний обед со своими друзьями в центр Остина. 

Луис обсудил проблемы с Биньямином, но, к сожалению, он не гово- 
рил в течение дня с Эммой Мурхаус. Это не было бы проблемой, если бы 
во время отправки Луисом отчета о дефекте всем тестировщикам Эмма не 
была занята запуском автоматизированных тестов производительности 
для Зоаг15, поэтому она не прочитала письмо. И это также небыло бы про- 
блемой, если бы тестовые скрипты Эммы не зависели от корректной ра- 
боты системы как раз в той части, которую Луис описал в своем отчете о 
дефекте как серьезно поврежденную. 

Эмма ушла в понедельник вечером с работы и не знала, что тесты про- 
изводительности 80]агіѕ дали неверные результаты. (Она не добавила в 
инструмент средства, которые позволили бы скриптам послать ей сооб- 
щение, если что-то в поведении было неверным.) И до утра вторника ей 
не было известно об этом упущении. Эмма была расстроена и огорчена. 
Сначала она пожаловалась коллегам, а затем рассказала Джамалу, что про- 
изошло. Джамал понимающе пожал плечами и сказал: “Причуды автома- 
тизированного тестирования”. Испытав облегчение, но не удивившись 
понимающей реакции Джамала, Эмма переработала тестовые скрипты 
для того, чтобы перезапустить их вечером во вторник. 


№ этапа Этап Выполнено? 


3.Е Если необходимо, подготовить отчеты о проблемах в системе М 
тестов и/или исправить их. 


В результате происшедшего инцидента Джамал понял, что ему нужно 
укрепить процесс. Он разослал группе тестирования следующее сообще- 
ние с пометкой “Срочно!”. і 


Всем! 


С момента начала тестирования в октябре мь использовали неформальньй 
процесс рассылки отчетов о дефектах по электронной почте всей группе 

с целью просмотра и получения информации. Считаю, что этот процесс спо- 
собствовал росту профессионализма при подготовке отчетов о дефектах 

и своевременному информированию о них тестировщиков. 
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Моя работа как менеджера состоит в том, чтобы делать хорошие идеи ча- 
стью нашего рабочего процесса. 8 этом отношении я допустил ошибку, по- 
скольку, возможно, сказал, что чтение сообщений с отчетами об ошибках 
является низкоприоритетной деятельностью, что мы можем делать это один 
раз в день или полностью игнорировать в случае сильной занятости. Одна- 
ко идти в ногу с результатами тестирования других и изучать, как эти 
результаты могут повлиять на проведение тестирования каждым из вас, яв- 
ляется на самом деле ключевым для эффективного и производительного тес- 
тирования. 


Я допустил ошибку управления и хочу ее исправить. Прошу вас считать 
чтение отчетов о дефектах, подготовленных другими тестировщиками, цен- 
тральной и повторяющейся частью вашей повседневной работы. Прошу регу- 
лярно до начала выполнения любого тестового сценария проверять почтовый 
ящик и знакомиться с отчетами о дефектах, подготовленными вашими колле- 
гами. Отправляя такие сообщения, прошу взять за правило в качестве пер- 
вого слова в строке "тема письма" писать "ОШИБКА:", а затем указывать 
номер ошибки и столько информации о ней, сколько уместится в строке. 


Некоторые из вас уже следуют описанной практике. Однако, поскольку я не 
внедрил эту практику с самого начала выполнения тестов, есть, по всей 
вероятности, такие, кто ей не следует. Для этих тестировщиков новая 
практика означает увеличение загрузки. Если вы уверены в том, что вво- 
димое в процесс выполнения тестов изменение означает существенное уве- 
личение загрузки и помешает завершить ранее порученные задачи в согла- 
сованные сроки, пожалуйста, не колеблясь, приходите ко мне, чтобы 
уточнить сроки выполнения работ и сферы ответственности. 


В заключение хочу подчеркнуть, что я отправляю это письмо не для того, 
чтобы бросить тень на чью-либо работу или подвергнуть сомнению чью-то 
точку зрения. Я весьма удовлетворен работой каждого из вас в этом не- 
простом проекте. Моя цель - скорректировать мое упущение в руководстве 
и улучшить процесс. Это увеличение загрузки в долгосрочной перспективе 
сэкономит наше время, способствуя повышению производительности и эффек- 
тивности. 


С уважением, 


Джамал 
№ этапа Этап Выполнено? 
4. Решать проблемы, препятствующие тестированию, при их М 


возникновении. 


После того как проблема с тестированием производительности была 
решена, тестирование продолжилось во вторник с большой скоростью, 
но тщательно продуманно. Луис продолжил с утра тестирование неуправ- 
ляемых файлов. Он обнаружил шесть разных проблем и написал шесть 
отчетов. Также вчерашнее непреднамеренное моделирование краха сер- 
вера показало наличие серьезной проблемы, которая в противном случае 
была бы пропущена. Обсудив проблему с Лин Цу, Луис потратил полчаса 
на обновление одного из тестовых сценариев для проверки обработки 
ошибок, чтобы учесть новое условие. Так случилось, что тестирование 
неуправляемых файлов не было полностью завершено до утра среды. 
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В 16.00 в среду, как и во все предыдущие дни, Джамал собрал группу 
тестирования для обсуждения результатов тестирования и передачи сме- 
ны. Он попросил каждого тестировщика сообщить, какие тесты они вы- 
полнили и сколько человеко-часов потратили на каждый из них, а также 
рассказать обо всех ошибках, обнаруженных при помощи каждого теста. 
По мере того как тестировщики докладывали о состоянии дел, Джамал 
обновлял измерения, используя сводную таблицу выполнения тестовых 
сценариев (см. рис. 13.4). После завершения выступлений Джамал обно- 
вил все проектные измерения, используя сводную таблицу комплектов 
тестов (см. рис. 13.5). Совещание обычно занимало примерно 45 минут, 
но сучетом объемов тестирования и ярких впечатлений от больной сбор- 
ки на этой неделе совещание длилось около часа. 

После совещания Джамал посмотрел на обновленные таблицы. Он 
увидел, что для этого тестового цикла тестирование безопасности и сек- 
ретности является наиболее рискованным. Биньямин увяз в болоте важ- 
ных функциональных ошибок. Другой младший тестировщик, Джон Ву, 
работающий в вечернюю смену, обнаружил массу проблем в документа- 
ции. Лин Цу управляет тестированием локализации и удобства использо- 
вания. (Оказалось, что ей нужно больше времени, чем запланировано, по- 
скольку были обнаружены ошибки регрессии в процессе инсталляции.) 
Значит, все, кому можно было бы поручить тестовые сценарии по безо- 
пасности и секретности, были заняты. 

Джамал понял, что у него нет другого выбора, кроме как вызвать ре- 
зервного тестировщика Джамала Брауна. Он знал, что, как бы ни старал- 
ся, он не сможет ни потратить 17 часов на тестирование в ближайшие три 
дня, ни “потущить другие пожары”, связанные с тестированием. Поэтому 
он заново спланировал тестирование, как показано на рис. 13.6. 


Рис. 13.4. Отчет о статусе тестовых сценариев (раунд 5, день 3) 
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Рис. 13.5. Отчет о комплектах тестов (раунд 5, день 3) 


№ этапа Этап Выполнено? 
5. Ежедневно готовить отчет о ходе тестирования, уточнять от- 194 
ветственных за выполнение тестов и пересматривать планы и 
приоритеты. 
6. Если необходимо, удалить невыполнимые или устаревшие тес- 


ты в порядке, обратном их приоритетности (сначала удалять 
тесты низших приоритетов, в последнюю очередь — высших). 


Четверг и пятница прошли почти по плану лишь с небольшими за 
держками. Лин Цуи Эмма, чьи несколько тестов должны были завершить 
ся утром в субботу, согласились встретиться с Джамалом в тестовой лабо 
ратории около 10.00, чтобы закончить тестовый цикл. Младший 
тестировщик Дейл, который обычно проводил приемочное тестирова 
ние тестовых версий, также предложил свои услуги, чтобы подготовит! 
тестовую версию для следующего цикла кутру понедельника. 


НО 


Е 


 Жеріая: зав ля 
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Рис. 13.6. Таблица тестовых сценариев, показывающая перепланирование 
выполнения комплекта тестов безопасности и секретности 
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Джамал посоветовался с инженерами-тестировщиками. Поскольку 
младшие тестировщики много работали в течение недели, Лин Цу, Эмма 
и Джамал решили не просить их приходить в субботу. Джамал сказал ин- 
женерам: “Нет смысла пытаться пробежать марафон как стометровку. 
У нас еще впереди три месяца работы, и я полагаю, что нам еще потребу- 
ются резервы этих ребят”. 

Вскоре после этого Джамал переговорил с Дейлом. * ейл, — сказал 
он. - Я ценю твое предложение, но я бы хотел, чтобы ты пришел в другой 
раз, и, возможно, я попрошу тебя потратить выходные на проект позже. 
Лучше дай мне твой волшебный контрольный список, и я проведу прие- 
мочное тестирование сборки сам”. 

Дейл улыбнулся: “Конечно. У меня в голове были другие идеи, но я по- 
лагаю, что могу передать список”. 

Затем Джамал связался с системным администратором Петрой, кото- 
рая обычно устанавливала тестовую версию, и попросил придти в выход- 
ной. Она согласилась, вероятно, с большим желанием, чем раньше, после 
того как узнала, что с ней рядом будет работать Джамал, лично выполняя 
приемочное тестирование. 

Наконец в субботу утром тестовый цикл был завершен, и новая версия 
прошла приемочное тестирование. Завершив первый цикл раунда 5, Джа- 
мал подвел итоги измерений и подготовил отчет о раунде. (В главе 15 мы 
увидим, как Джамал представляет результаты цикла на совещании о со- 
стоянии проекта “Суматра”.) Затем он положил все документы, которые 
он обновил и создал заново, в проектный репозиторий. 


№ этапа Этап Выполнено? 

7. Периодически отчитываться о ходе и результатах тестового 
цикла. 

8. Поместить все документы о ходе работ, начальные состояния, 


обновленные средства тестирования, другие элементы систе- 
мы тестов и прочую информацию, получаемую на постоянной 
основе, в проектную библиотеку или систему управления кон- 
фигурациями. Вести контроль изменений всех элементов. 


Построение успешного процесса выполнения 
тестов 


Как и вершина айсберга, процесс выполнения тестов — та часть тестиро- 
вания, которая видна, но она держится на плаву благодаря качественной 
работе в ходе предыдущих восьми процессов. Какие же действия и дости- 
жения группы тестирования способствуют успешному процессу выполне- 
ния тестов? 


Выявление опасных мест 


В ходе выполнения тестов я использую различные источники информа- 
ции, чтобы выдвинуть обоснованные гипотезы по поводу того, где нахо- 
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дятся наиболее неприятные ошибки, и в первую очередь проверяю эти 
области. Когда я только начинаю выполнение тестов, я применяю резуль- 
таты анализа рисков качества (см. главу 2), чтобы определить, с чего на- 
чать тестирование. Позднее, когда я уже ближе познакомлюсь с систе- 
мой, у меня появляются более удачные идеи о том, где располагаются 
места наибольшего риска: там, где я нашел ошибки, и там, где яеще нетес- 
тировал. Воспользовавшись этими знаниями, я могу уточнить, что тести- 
ровать дальше. (Тем не менее я должен быть осторожным, чтобы не по- 
зволить строгим техническим соображениям, например искать там, где 
мы уже нашли ошибки, скрыть от меня тот факт, что риски, связанные с 
применением системы заказчиком, и другие соображения бизнеса также 
должны оказывать влияние на приоритетность тестирования.) В нашем 
примере Джамал сначала концентрирует внимание на ранее заблокиро- 
ванных функциональных тестах, а также на тестах секретности, безопас- 
ности и обработки ошибок, на которые оказывают воздействие новые 
свойства последней версии. 

Меня также волнуют два особых риска качества: исправления дефек- 
тов, которые на самом деле не решают проблему, и исправления дефек- 
тов, которые порождают новые проблемы. Эти риски являются сферой 
проверочного и регрессионного тестирования соответственно. Посколь- 
ку исправления ошибок, которые не решают проблем, особенно пробле- 
матичны, я предпочитаю начинать с этих тестов каждый тестовый цикл. 

В главе 6 я подробно рассмотрел стратегии работы с риском регрес- 
сии, но здесь хотел бы отметить, что выполнение тестов -— это та фаза, ко- 
гда нужно запускать эти стратегии в действие. Проблема может возник- 
нуть для стратегий риска регрессии, которые предполагают повторение 
тестов. Этот подход может конфликтовать с нацеленностью на выполне- 
ние новых тестов и проверку исправлений дефектов. Я не рекомендую от- 
казываться от тщательно спланированной стратегии регрессии при пер- 
вых признаках проблем в проекте, но можно пересмотреть подход, 
который предполагает повторение большого числа тестов, если результа- 
ты тестирования показывают небольшой риск регрессии, тогда как дру- 
гие риски оказываются значительно более серьезными, чем считалось 
первоначально. 

Другая опасность — это обнаружение проблем, которых мы не ожида- 
ли. Тщательно спланированное методически верное множество процес- 
сов тестирования, аналогичное описываемому в этом книге, помогает 
предотвратить классические ошибки тестирования . Однако оно может 
породить опасные темные пятна. Ошибочное предположение в ходе ана- 
лиза рисков качества может пройти волной через все процессы оценки 
затрат, планирования тестирования и разработки системы тестов, поро- 
ждая большие и незаметные пробелы в тех местах, которые действитель- 
но важно проверить. Простой взгляд на обнаруженные ошибки, чтобы 
понять, где есть еще ошибки, не решит эту проблему, поскольку это вам 
ничего не скажет об ошибках, которых вы не нашли, так как не тестирова- 
ли эти области совсем. Вот почему сейчас яусиливаю свои планы тестиро- 


Другой взгляд на ошибки тестирования приводится в статье Брайана Марика (Вгіап 
Манск) "Сіаззіс Тезция Мізакез» на уму Тез пр.соп. 
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вания за счет исследовательского тестирования как части общей страте- 
гии. В нашем примере Джамал включил исследовательское тестирование 
в оценку затрат (см. главу 3) и в план тестирования (см. главу 6)!. 

Наконец, тестировщики не должны оставлять без внимания ошибки, 
которые не относятся к краткосрочным целям тестирования. В случае ис- 
пользования подробных ручных тестовых скриптов или проведения ав- 
томатизированного тестирования мы можем попасть в ловушку, если бу- 
дем игнорировать ошибки, не относящиеся непосредственно к тому, что 
мы тестируем. Например, если я тестирую функциональность, связанную 
с открытием файла, и замечаю проблему с утилитой импорта файла, яв- 
ляющуюся целью другого теста, я должен потратить время на исследова- 
ние проблемы и написание отчета об ошибке. Это особенно важно, если 
ошибка, которую я заметил, не покрывается другим тестом. Данный во- 
прос относится к теме тестирования по возможности, которая обсужда- 
лась в главе 2. Часть работы тестировщика — представить ожидания и 
мнение о системе разумного пользователя. Когда я тестирую, я всегда ищу 
такое поведение программы, которое, будучи разумным пользователем, я, 
счел бы раздражающим, запутывающим, некорректным или причиняю- 
щим беспокойство. Как тест-менеджер я постоянно напоминаю группе 
тестирования о необходимости делать то же самое. 


Генерация, сбор и распространение значимой информации 


Точно так же, как фармацевтические компании тестируют лекарства, а 
инженеры проверяют машиностроительные материалы, мы тестируем 
программы, чтобы получить новые знания о них. Цель этого процесса — 
получение информации. Таким образом, имеет смысл спланировать экс- 
перименты — наши тесты — так, чтобы собрать максимум информации и 
передать ее тем, кто умеет ею пользоваться. 

Информация распространяется в основном вне группы тестирования. 
Эти темы более подробно рассматриваются в главах 14 и 15, сейчас же от- 
метим, что основная цель тестирования — получение информации, кото- 
рую проектная группа может использовать для принятия разумных реше- 
ний относительно качества. Комиссия по разбору дефектов или группа 
управления изменениями может расставить приоритеты ошибок и ре- 
шить, какие из них устранять (см. главу 16). Разработчики могут принять 
решение, как исправить эти ошибки. Группа управления проектом может 
решить, как скорректировать работы, чтобы проект двигался в нужном 
направлении. Чтобы способствовать принятию разумных и обоснован- 
ных решений, процесс выполнения тестов должен обеспечивать сбор ре- 
зультатов тестирования в ясных отчетах и передачу результатов всем за- 
интересованным сторонам. В нашем примере тестировщики немедленно 
рассылают отчеты о дефектах, а тест-менеджер готовит еженедельный 
отчет о результатах тестового цикла для руководства. Как указывалось в 


Для получения дополнительной информации о методах исследовательского тестирова- 
ния я рекомендую “Тестирование программного обеспечения" Канера, Фолка и Нгуена, “Уроки, по- 
лученные при тестировании программного обеспечения" Канера, Баха и Петтикорда, и мер-сайт 
Джеймса Баха мум.ѕайѕбсе.сот. 
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главном примере в главе 12, Джамал присутствует на еженедельных сове- 
щаниях группы управления изменениями, на которых обсуждают и при- 
нимают решения по дефектам. 

Другое направление распространения информации — внутри группы 
тестирования. Результаты предыдущих тестов могут оказывать влияние 
на последующие тесты. Хорошим примером этого является рассказ Луиса 
об ошибке со шрифтами, которую он обнаружил. Однако мы видели и от- 
рицательный пример, когда Эмма не прочла отчет об ошибке, подготов- 
ленный Луисом. 

Это нарушение процесса имело два отрицательных последствия. Пер- 
вое – выполнение работы заново. Эмма вынуждена была потратить время 
и силы на повторное выполнение теста производительности для 50Їагіз. 
Второе, возможно, более серьезное последствие — однодневная задержка 
в обнаружении ошибок, относящихся к производительности. Вы можете 
сказать: “Что значит один день?” Но проект — это ничто другое, как после- 
довательность дней, а дни складываются в недели . Исследование моде- 
лей устранения дефектов показывает, что более раннее обнаружение и 
исправление дефектов снижает общее число обнаруженных дефектов, 
что в итоге экономит деньги и время". Использование перекрестных про- 
смотров отчетов об ошибках и отчетов о ходе тестирования может умень- 
шить коммуникационные проблемы. Тест-менеджер должен бытьуверен, 
что тестировщики решают эти задачи. Письмо Джамала группе тестиро- 
вания — это пример процесса, который может хорошо работать, и при- 
мер управления, которое может внедрить этот процесс”. 

Как показывает этот пример, внутренняя информация о текущем 


проекте может способствовать улучшению системы тестов и процесса 


тестирования. Можно сказать, что в то время как система тестов прове- 
ряет систему, предназначенную для тестирования, в процессе выполне- 
ния тестов, система, предназначенная для тестирования, также прове- 
ряет систему тестов и процесс выполнения тестов. Это означает, что 
проницательные тестировщики и тест- менеджеры могут собирать ин- 
формацию о качестве системы тестов и процесса выполнения тестов и 
находить возможности для их усовершенствования. В рассматриваемом 
нами примере Луис и Лин Цу внесли изменение в один из тестовых сце- 
нариев на основе случайно обнаруженной ошибки. В ходе первоначаль- 
ного отбора тестов и назначения ответственных за их выполнение Джа- 


Более 25 лет назад Фред Брукс рассматривал опасность небольших отставаний и разъе- 
дающий эффект такого отношения к небольшим отставаниям проекта в книге “Мифический 
человеко-месяц». Позднее Том де Марко (Тот РеМагсо) писал в книге “Тйе Деадйте», что “суще- 
ствует бесконечное число способов потерять день для проекта, но ни одного способа вер- 
нуть этот потерянный день обратно». Берегите время и энергию вашей группы с самого на- 
чала проекта, когда кажется, что еще всего много, позднее вы будете приятно удивлены этой 
предусмотрительностью, когда время сожмется, а энергии станет меньше. 


См., например, книгу Стефана Кана (Ѕ‹ерһеп Каһп) “Мен; апа Мойеіѕ т Зойшате Оца Шу 
Епріпеегіпр. бесопа Ейійот». 


Заметим, что Джамал разобрался, что сбой в работе связан с проблемой в процессе, анес 
людьми. Я упоминал ранее эксперимент Деминга с красными бусинками в качестве примера 
того, почему руководство должно брать ответственность за недостатки процессов. Вместо 
того чтобы подвергнуть наказанию Эмму (она следовала процессу так, как она это понима- 
ла), Джамал принял ответственность за инцидент на себя и исправил процесс. 
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мал угочнил время на выполнение тестов на основе информации о 
предыдущем тестовом цикле. 

Внугренняя информация необходима также для управления задачами, 
которые должны быть выполнены. Ведущий тестировщик или тест- 
менеджер должен иметь возможность проверить, что группа тестирова- 
ния завершает все плановые действия тестирования. Здесь пригодится 
раздел “Выполненная работа” сводной таблицы комплектов тестов. В на- 
шем примере Джамал посмотрел на ситуацию с выполнением работ иуви- 
дел, что многие из комплектов тестов требуют больше времени, чем за- 
планировано. Это заставило его проанализировать сами комплекты 
тестов, которые еще остались незавершенными. Он понял, что опреде- 
ленные тесты не могут быть завершены или даже выполнены без приня- 
тия корректирующих мер. Качественный процесс тестирования позволя- 
ет руководителю видеть такие ситуации по мере их развития и 
предпринимать меры по снижению рисков. 


Правильная интерпретация результатов тестирования 


Основной характеристикой, которая отличает ценную информацию от 
бесполезного шума, является точность. Результаты тестирования, кото- 
рые мы сообщаем, должны быть точными. В процессе выполнения тес- 
тов, описанном выше, подэтапы 3.С, 3.0 и 3.Е требуют от тестировщика 
тщательной проверки несоответствия в результатах тестирования; нуж- 
но различать ошибки в системе, предназначенной для тестирования, 
и ошибки в системе тестов. Определение трех различных этапов вместо 
одного “Подготовить отчет об ошибке, если ожидаемые и фактические 
результаты не совпадают” указывает на необходимость правильной ин- 
терпретации результатов тестирования. 

Выполнение тестов — это процесс, осуществляемый людьми. Наши 
возможности наблюдения и оценки иногда дают сбой. Наше ожидание 
корректного поведения системы иногда неверно. Непостижимые систе- 
мы, передаваемые на тестирование, иногда скрывают подтверждения 
своего верного и неверного поведения. Мы можем ошибочно принять 
проблему в тестовой среде, скриптах, инструментах и других частях сис- 
темы тестов за проблему в тестируемой системе. По этой и другими при- 
чинам мы можем сообщить о сбое, в то время как программа работает вер- 
но, или наоборот, что еще хуже (см. таблицу 13.1). 


Таблица 131. Выходные данные по интерпретации результатов 


тестирования 
Тестировщик отчихывается ... 
Поведение ... о прохождении теста об ошибке 
Корректное Повышенное доверие Ненужное беспокойство 
Некорректное Ошибочное доверие Полезная диагностическая 


информация 
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Такие виды просчетов не должны удивлять нас. Для пояснения давай- 
теувеличим графическое изображение этапа 3 процесса выполнения тес- 
тов (см. рис. 13.7). Сучетом всех меняющихся частей картинки неверная 
интерпретация может стать проблемой. Добавьте к этому, что все тести- 
ровщики и сотрудники проектной группы, вероятно, должны работать 
с системой тестов и системой, предназначенной для тестирования, пока 
мы выполняем тесты, и такие недоразумения становятся еще более веро- 
ятными!. 

Чтобы решать проблемы наблюдательности тестировщика и его спо- 
собности к оценке, обычно я прошу старших тестировщиков проверять 
результаты тестирования младших тестировщиков и назначаю разных 
тестировщиков ответственными за выполнение одних и тех же тестовых 
сценариев в ходе следующих друг за другом циклов. Полное решение про- 
блемы распознавания корректного и некорректного поведения систе- 
мы — проблемы оракула, рассмотренной в главе 10, — зависит от наличия 
непротиворечивых спецификаций требований и архитектуры и надеж- 
ного способа прогнозирования корректного ответа на любое обращение 
к системе. Когда я опускаю эти элементы, я, как правило, делаю ошибки в 
отчетах о дефектах. (В главе 14 рассматриваются способы решения поли- 
тических проблем, связанных с информированием о несуществующих 
ошибках, а в главе 16 обсуждаются некоторые идеи по поводу того, как ка- 
чественный процесс управления изменениями может разрешить вопро- 
сы, связанные с неопределенными отчетами об ошибках.) Проблема с за- 
гадочными программами сводится к написанию тестопригодных 
программ. Только высшее руководство может решить эту проблему, обес- 
печивая вовлечение тестировщиков в проект во время проектирования и 
разработки программы. 

Что должны делать тестировщики, если они обнаружили проблему 
в системе тестов во время тестирования? Процесс, описанный выше, тре- 
бует немедленной корректировки неверного теста. Некоторые предлага- 
ют работать с системой тестов так же, как с системой, предназначенной 
для тестирования: подготовить отчет об ошибке, предоставить комиссии 
по разбору дефектов право принять решение, стоит ли исправлять ее, со- 
бирать измерения, связанные с проблемами качества системы тестов, — 
в общем, все, что необходимо. Другими словами, поскольку система тес- 
тов проверяет систему, предназначенную для тестирования, и наоборот, 
система, предназначенная для тестирования, проверяет систему тестов, 
симметрия означает, что мы должны следовать процессу, когда обстоя- 
тельства изменяются. 

В большинстве проектов, в которых я участвовал, такой процесс не 
имел смысла. Вернемся к вопросу качества. Если мы признаем, что арбит- 
ром качества в последней инстанции является пользователь или заказ- 
чик, то система, предназначенная для тестирования, и система тестов 
имеют принципиально разных заказчиков и пользователей. Система, 
предназначенная для тестирования, является внешним передаваемым 


1 Стив Сплейн (Ѕ‹еуе Зріаїпе), один из рецензентов, отметил, что это особенно верно, 


“если не было предпринято никаких усилий, для того чтобы разбить [или] скоординиро- 
вать использование... разделяемых тестов и данных”. Потенциальные проблемы становятся 
еще более острыми, чем больше группа и чем сложнее тестовая среда. 


га1огьем ехнәһо "Є| евви | 


Подготовить отчет о результатах 
и отреагировать ка них 


Начальное условие і Выполнить тестовый сценарий Тестовое условие Оценить резупьтаты тестирования 
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Рис. 13.7. Выполнение тестовых сценариев 


382 


Часть Ш. Проведение 


продуктом, разработанным для решения реальных проблем для заказчи- 
ков и пользователей, которые оплачивают создание системы. Система 
тестов — это обычно внутренние передаваемые результаты, которые при- 
меняется теми же людьми, которые ее разработали, для выполнения сво- 
их обязанностей по тестированию. Система, предназначенная для тести- 
рования, является продуктом. Система тестов — это инструмент, 
помогающий создать продукт. 

Итак, нередко сотрудники, создающие тестовые сценарии, и сотруд- 
ники, которые их выполняют, -- это разные люди. Например, консуль- 
танты иногда создают системы тестов и инструменты для компаний. 
В некоторых случаях проблемы качества системы тестов могут иметь не- 
приемлемые последствия, например, в системах с высокими требова- 
ниями к безопасности. Фиксация процесса для создания системы тестов 
может добавить формализм, который придаст уверенности в том, что 
передается качественная система тестов. 

Наконец, отмечу, что тестировщики не всегда могут знать с полной 
определенностью, в каком из четырех квадрантов таблицы 13.1 они на- 
ходятся; на выяснение этого требуется время. Исследование ошибок 
и поиск других необычных или многообещающих (с точки зрения обна- 
ружения ошибок) вариантов поведения системы требует непрогнози- 
руемых объемов затрат. Поэтому фактическое количество человеко- 
часов, необходимых для выполнения множества тестов, может сущест- 
венно отличаться от плана. Тестировщики всегда должны внимательно 
следить, на что расходуется их время. Ведущие тестировщики и менед- 
жеры должны оказывать помощь своим сотрудникам в уравновешива- 
нии необходимости двигаться вперед по запланированным тестовым 
сценариям и необходимости с полной определенностью понимать 
смысл результатов тестирования. 

Не все ошибки заслуживают одинакового исследования. Периодиче- 
ски возникающий дефект, когда при неправильном указании шрифта по- 
является малопонятное сообщение об ошибке один раз на десять обраще- 
ний, по всей вероятности, может быть спокойно проигнорирован, чтобы 
не откладывать выполнение других тестов на часы. Однако периодиче- 
ски возникающий дефект, который время от времени разрушает базу дан- 
ных разделяемого доступа, может служить основанием для отсрочки вы- 
полнения тестового цикла, пока сбой не будет локализован и проблема не 
станет воспроизводимой. 


Демонстрация надлежащего отношения 


Тема корректной интерпретации результатов подводит нас к вопросу от- 
ношений. Качественный процесс тестирования должен укреплять надле- 
жащее отношение тестировщиков, а надлежащее отношение тестиров- 
щиков точно так же повышает возможности процесса тестирования 
в получении полезных результатов. Как отмечалось в главе 8, надлежащее 
отношение тестировщика к делу включает в себя профессиональный пес- 
симизм, разумную любознательность и способность концентрироваться. 
Поскольку тестировщики должны сохранять скепсис и выступать в про- 
екте разработки в роли профессиональных пессимистов, я призываю 
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кактивной позиции в отношении подготовки отчетов об ошибках в ходе 
тестирования. Такой подход имеет несколько следствий. 


ш Если тестировщики находятся в сомнении, они принимают за осно- 
ву, что наблюдаемое поведение является неверным, пока не убедят 
себя в обратном. 


ш Тестировщики сообщают о любой ситуации как об ошибке, если эк- 
ранная справка, руководство пользователя или любая другая доку- 
ментация указывает, что правильное поведение системы отличает- 
ся от наблюдаемого. 


и Тестировщики всегда сообщают обо всех событиях, которые ведут к 
катастрофическим вариантам поведения, независимо от того, на- 
сколько часто они происходят или являются невоспроизводимы- 
ми. Такие варианты поведения включают в себя любую потерю дан- 

ных, крах, остановку, зависание системы и любые другие проблемы 
надежности, качества данных или серьезного снижения произво- 
дительности, которые затрагивают систему, предназначенную для 
тестирования, центральную систему, любое сосуществующее про- 
граммное обеспечение, любую смежную или взаимодействующую 
систему. 


и Наконец, тестировщики сообщают обо всех обстоятельствах, при 
которых система, предназначенная для тестирования, не соответ- 
ствует разумным ожиданиям поведения или качества программы 
или является запутанной, обманчивой или противоречивой. 


Такой способ мышления, однако, должен быть сбалансирован с ходом 
проекта. На ранних стадиях тестирования качество системы обычно не- 
высокое. Тестировщики должны сосредотачиваться на поиске опасных 
проблем, не тревожась, например, за ошибки в правописании в руково- 
дстве пользователя. По мере улучшения системы тестировщики будут на- 
водить глянец на соответствие системы требованиям, хотя в этом случае 
их часто критикуют за интерпретацию результатов тестирования, считая 
их отчеты о дефектах придирками. Мы не должны стыдиться, размещая 
отчеты об ошибках с низким приоритетом в соответствующие моменты 
проекта. Это одна из форм разумной любознательности. 

Способность концентрироваться означает, что квалифицированные 
тестировщики внимательно следят и сразу информируют о расхождениях в 
интерпретации данных о работе системы. Расхождения в интерпретациях 
могут возникать не только между тестировщиком и программистом, но и 
между двумя программистами, которые готовят взаимодействующие ком- 
поненть, являющиеся источником большинства ошибок, обнаруживае- 
мых в ходе фазы комплексного тестирования. Классический пример такой 
ошибки: в ходе полета на Марс, осуществлявшегося НАСА, возникла нераз- 
бериха с использованием метрических и английских единиц измерения 
данных, в особенности касающихся скорости и тормозной тяги. Использо- 
вание различных единиц разными программистами привело к полному 
провалу полета и к потере всей полученной информации, когда спускае- 
мый аппарат на большой скорости врезался в марсианскую поверхность 
и предположительно развалился на куски. 


384 


Часть Ш. Проведение 


В таких случаях ошибка существует не в одном или в другом компонен- 
те, а во взаимодействии компонентов. До того как появляется строчка с 
неверным кодом, ошибка одновременно существует в головах двух раз- 
ных людей. Если бы нужный человек, вероятно тестировщик, в нужное 
время, например в ходе определения требований, задумался о том, чтобы 
задать обоим программистам вопрос о единицах измерения: английские 
или метрические, — можно было бы избежать этого неудачного сценария. 

Поэтому тестировщики должны быть бдительными к появлению при- 
знаков несогласия или различного понимания внутри групп программи- 
стов. Иногда задавая “глупые вопросы”, например: “Простите, но я запу- 
тался: мы используем метрические или английские единицы в проекте?”, 
можно вызвать обсуждения, которые вскроют непонимание, прежде чем 
это непонимание превратится в опасные, дорогие и трудно диагности- 
руемые проблемы в ходе системного тестирования или, что еще хуже, 
позднее. Более 25 лет назад в первом издании книги “Мифический человеко- 
месяц" Фред Брукс писал о проектах, которые осуществлялись в 60-е годы 
прошлого века: “Задолго до написания кода спецификация должна быть 
передана сторонней группе тестирования для тщательного рассмотре- 
ния полноты и ясности. Как считает [В. А.] Высоцкий [из проекта 
Заїермага, выполнявшегося в Ве! Те!ервопе І абогаќогіеѕ], сами разработ- 
чики сделать это не могут: “Они не могут признаться в том, что не видят 
проблем, они будут счастливо прокладывать свой путь через пропущен- 
ные и темные места”. 

Ошибка — всегда ошибка, независимо от того, есть она в компоненте 
или в интерфейсе компонентов, в системе, в архитектуре или в требова- 
ниях. Наиболее производительные группы тестирования, в которых я ра- 
ботал, имели явное или неявное разрешение сообщать о таких видах оши- 
бок и привлекались к работе над проектом достаточно рано, чтобы 
сделать что-либо полезное на каждом из этапов. 


Эффективная работа 


До некоторой степени эффективный процесс тестирования основан на 
эффективной системе тестов. Это возвращает нас к проблемам разработки 
системы тестов, которые обсуждались в главе 11. Например, минимизация 
взаимозависимостей тестовых сценариев и разделяемых множеств тесто- 
вых данных предотвращает ненужные переработки сценариев, задержки 
и, возможно, неверную интерпретацию результатов тестирования. 
Однако вопросы эффективности возникают также в ходе выполнения 
тестов, даже при самой эффективной системе тестов. Как тест-менеджер 
я хочу добиться минимального перекрытия работ и избежать задержек 
при проведении тестирования. Часть этой работы требует ясной поста- 
новки задач для всех тестировщиков, какие тесты они должны выполнять 
и когда. В нашем примере Джамал использует столбец “Ответственный” в 
сводной таблице тестовых сценариев для определения ответственного за 
выполнение каждого теста. С помощью столбца “Плановая дата” он упо- 
рядочивает тесты для достижения максимальной эффективности и для 


1 сы. “Мифический человеко-месяи”, с. 142. - 
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получения информации в нужном порядке. По мере осуществления цикла 
и ответственные, и плановые даты могут меняться для некоторых тесто- 
вых сценариев, например, когда Джамал принял на себя ответственность 
за тесты безопасности и секретности. В таких ситуациях ведущий тести- 
ровщик или тест-менеджер должен обсудить изменения ответственности 
и плановых дат с группой тестирования. 

Здесь может возникать путаница с двумя серьезными последствиями. 
Неверное управление драгоценными ресурсами (тестировщиками и за- 
планированным временем), доверенными тест-менеджеру, является дур- 
ным тоном. Часто тест- менеджеры требуют еще больше сверхурочной ра- 
боты от своей команды, чтобы спасти сроки. А это приводит к потере 
авторитета и к снижению возможностей руководителя добиться наилуч- 
шей работы от своей группы . 

Это указывает на то, что группа тестирования должна иметь возмож- 
ность приспосабливать процесс и выполнение запланированных тестов 
к меняющимся обстоятельствам. Часть тестирования состоит в обнару- 
жении непредсказуемого поведения и в исследовании этих аномалий для 
того, чтобы подготовить подробные и работающие отчеты об ошибках 
(см. главу 14). Поскольку поведение является непредсказуемым и по- 
скольку мы не можем со 100%-ной точностью прогнозировать, сколько 
ошибок мы обнаружим, процесс тестирования порождает свой собствен- 
ный поток событий. Кроме того, внешние события, например задержка 
предоставления версий, уточнение состава сборок, изменения в приори- 
тетах руководства, вносят изменения в ход процесса. Тестировщики не 
могут предотвратить этих изменений, поэтому процесс тестирования 
должен аккумулировать их. В нашем примере Джамал приспосабливался 
к изменениям как внутренним — неправильному обмену информацией 
о результатах тестирования, так и внешним — высокому уровню содержа- 
ния дефектов в Зрееду\/тиег и неожиданной остановке тестового серве- 
ра системным администратором. Джамал пересмотрел ответственных за 
выполнение тестовых сценариев, добавил дополнительные ресурсы, из- 
менил плановые даты заверщения тестов и перенес выполнение тесто- 
вых сценариев низшего приоритета на следующий цикл тестирования. 

В качестве отступления рассмотрим бесполезную трату времени и за- 
держки, возникшие в нашем примере, когда системный администратор, 
не входящий в группу тестирования, остановил сервер, который Луис ис- 
пользовал для выполнения теста. Тему управления конфигурацией среды 
тестирования я подробно рассматривал в моей первой книге “Мапаріпр 
йе Тезійпе Ргосез5", но я бы хотел отметить, говоря о выполнении тестов, 
что группа тестирования должна иметь полный контроль над тестовой 
средой в период проведения тестирования. 

Серьезное нарушение процесса возникает тогда, когда ошибка, опи- 
санная в главном примере книги, происходит более чем один-два раза в 
ходе тестирования. В ситуациях, аналогичных сложившейся при тести- 


1 № 
Неуважит ельное отношение ко времени сотрудников группы — смертный грех руково- 


дства. Однажды я стал свидетелем ухода ведущего системного архитектора проекта после 
таких событий с позорной, внезапной и эмоциональной вспышкой гнева в середине совеща- 
ния. Более глубокое рассмотрение этой и других ошибок руководства можно найти в книге 
Тома де Марко и Тима Листера “Реоріешате». 
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ровании проекта "Суматра», когда внешние по отношению к группе тес- 
тирования сотрудники имеют права администратора на тестовую среду, 
поскольку они занимаются ее поддержкой, трудно гарантировать, что ни- 
кто не изменяет тестовую среду без санкции тест-менеджера или ведуще- 
го тестировщика. 

Бывает так, что люди, ответственные за поддержку тестовой среды, 
создают больше проблем, чем оказывают помощь. В моей практике были 
случаи, когда администраторы забирали оборудование из тестовой лабо- 
ратории, хотя оно приобреталось исключительно для тестирования. При 
таком отношении лучше попытаться перенести поддержку тестовой сре- 
ды в группу тестирования, даже если для этого придется уменьшить обь- 
ем тестирования, и закрыть логический (электронный) и физический 
доступ к тестовому оборудованию для всех сотрудников, не входящих в 
группу тестирования. Это могут быть секретные пароли, брандмауэры, 
замки, отдельные помещения для тестовой лаборатории, карточные клю- 
чи и т.п. В противном случае эффективность тестирования может сни- 
зиться до нуля. 

Наконец, эффективный процесс тестирования должен иметь мини- 
мально возможные накладные расходы. Другими словами, мы должны по- 
святить по возможности большую часть времени тестированию и другим 
действиям, значимым для компании. Заметим, что ежедневные совеща- 
ния, посвященные итогам тестирования, перекрестное чтение отчетов 
об ошибках и другие неформальные действия тестирования, стимулирую- 
щие обмен информацией и знаниями, не являются накладными расхода- 
ми, поскольку способствуют повышению эффективности тестирования. 
Однако следование неуместно сложному или трудоемкому процессу, ис- 
пользование процессов, отягощенных подготовкой большого количест- 
ва документов, которые не будут использоваться впоследствии, проведе- 
ние продолжительных совещаний, когда один человек докладывает 
руководителю о состоянии дел, в то время как другие просто ожидают 
своей очереди, — все это примеры накладных расходов. 


Решение проблем 


Поскольку процесс выполнения тестов подвергается всякого рода не- 
предсказуемым и внешним воздействиям, в нем возникают проблемы. 
Рассмотрим некоторые из них. 


Работа с дополнительными сменами и субподрядчиками, 
проводящими тестирование 


В главе 6 мы видели, как Джамал решил использовать вечернюю смену. 
Он принял это решение, основываясь на ограничениях тестовой среды. 
Это обычная причина, по которой используются вечерняя или даже ноч- 
ная смена и выходные. Я предпочитаю вечерние смены и работу в выход- 
ные, если чувствую недостаток в редких прототипах Интернет- 
приложений и надо выполнить быстро большое количество тестов. Если 
тестирование должно проводиться в производственной системе, уста- 
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новленной науниверсальной машине, которая просто не может быть пол- 
ностью отдана на растерзание тестировщикам в обычные рабочие часы, 
большую часть тестирования приходится проводить в нерабочее время. 
Другой случай — проведение энергичного тестирования перегрузок 
24 часа в день. Это означает, что нам приходится все время быть рядом с 
тестами. Когда я был менеджером проекта по созданию тестовой лабора- 
тории, мы обычно работали и в вечернюю смену, и в выходные. 

Дополнительными сменами не так уж трудно управлять, поскольку вы в 
состоянии держать в голове несколько объектов. Основной вопрос — это 
коммуникация. Людям, которые не находятся в одно время в одном месте, 
труднее общаться, а выполнение тестов (наряду с подготовкой отчетов о 
дефектах) —это определенно та часть процесса тестирования, для которой 
взаимодействие сотрудников группы тестирования имеет ключевое значе- 
ние. В нашем примере Луис и Эмма столкнулись с проблемой коммуника- 
ции, работая в одной смене, что показывает, как легко возникают такого 
рода проблемы. Вечерние смены ограничивают возможности коммуника- 
ции, а ночные смены и работа в выходные снижают эти возможности еще 
больше. Группа тестирования должна предпринять все возможные усилия 
для улучшения коммуникации, а тест-менеджер обязан внедрить соответст- 
вующие процессы. В проекте с Интернет-приложением у нас ежедневно 
были двухчасовые перекрытия с 15 до 17 часов. В это время вечерняя смена 
читала электронные сообщения, поступившие за день, и задавала вопросы 
до того, как дневная смена заканчивала работу. 


| и (примерно с8.00 до 17, т "Обычно: это. одна смена О 16 00. 
до 1.00), ночная смена (примерно с 0.00 до 9.00), работа в выходныги праздниме. 
`ныедни (любая из указанных смен, но неврабочиедни). Сра зните с перера- 
боткой (оуегіше) - работа свыше 40 часов в неделю, может включа 

‚ в себя работу в. любые смены, З 


Часть общения состоит в сборе информации о состоянии дел. Полез- 
ны ежедневные совещания, посвященные ходу тестирования и происхо- 
дящие в период передачи смен. На этих совещаниях мы говорим о тести- 
ровании, которое состоялось днем и предыдущим вечером, а также 
обновляем таблицы отслеживания тестовых сценариев. 

Еще одна проблема — планирование. Все хотят знать, в какой смене ив 
какие дни они работают. Самый простой случай, когда сотрудники рабо- 
‘тают в одну и ту же смену в течение всего проекта. Однако это не всегда 
возможно. Некоторые тестировщики считают работу в дополнительные 
смены слишком обременительной. И поэтому может быть необходим не- 
который способ ротации смен. Мой опыт показывает, что премии, вы- 
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плачиваемые бригадам, работающим в вечерние смены и в выходные, 
обычно делают дополнительные смены желательными для определенно- 
го круга людей, что уменьшает проблему. 

Другой вопрос — поддержка. Если группа тестирования не администри- 
рует сеть тестирования, необходимо подыскать системного администрато- 
ра или сотрудника поддержки сетевых операций, который обеспечит под- 
держку во внерабочее время. Этот сотрудник должен предоставить группе 
тестирования номера пейджера, домашнего и сотового телефонов и т.п. 
Он должен отвечать на звонки днем и ночью и в целом быть готов к тому, 
что поздним вечером или даже ранним утром его сон может быть прерван 
срочным запросом группы тестирования. Я считаю решение этой пробле- 
мы более сложным делом, нежели подбор тестировщиков для работы в до- 
полнительные смены. В главном примере книги Джамал очень осторожно 
решал эту проблему в ходе планирования тестирования. Если вы не реши- 
те ее до начала выполнения тестов, то рискуете столкнуться с негодовани- 
ем, деструктивным формальным согласием и другими формами активного 
и пассивного сопротивления, включая прямой отказ. 

Наконец, рассмотрим вопросы материально-технического обеспече- 
ния. Сотрудники, работающие в дополнительные смены, должны иметь 
соответствующие пропуски. Во время дополнительных смен должны ра- 
ботать средства кондиционирования воздуха. Должны быть предоставле- 
ны коды сигналов тревоги. Служба безопасности должна быть оповеще- 
на. Внутренняя телефонная сеть должна быть сконфигурирована для 
использования во внерабочие часы. Администрация зданий должна быть 
заинтересована в решении возникающих вопросов. 

Передача всего тестирования или его части субподрядчику (аутсор- 
синг) обычно порождает те же проблемы, что и дополнительные рабочие 
смены, только в большей степени. В этих случаях общение обычно идет 
по электронной почте и телефону. Время от времени случаются визиты 
друг к другу, но редко бывает, что все сотрудники тестовой лаборатории 
приезжают к клиенту и наоборот. Кроме того, визиты друг к другу посвя- 
щаются в основном презентациям руководству и обсуждению вопросов 
заключения и оплаты контракта, а не тактическому взаимодействию меж- 
ду непосредственными исполнителями. Общение по электронной почте 
и телефону осложняется разными часовыми поясами, что ограничивает 
периоды одновременной работы и возможности диалога в реальном вре- 
мени, в интерактивном режиме по мере надобности. Персонал поддерж- 
ки тестирования, например системные администраторы, обычно не от- 
вечают за обеспечение поддержки тестовой лаборатории субподрядчика. 

Из-за широкой клиентской базы большинство компаний, выполняю- 
щих тестирование, не берутся за проведение частной экспертизы, необ- 
ходимой для поддержки системы. В ходе тестирования возникают как 
небольшие, так и серьезные затруднения при инсталляции, сопровож- 
дении или работе с системой, в то же время соответствующий специа- 
лист внутри группы тестирования может решить их за минуты. Такие за- 
труднения могут выводить систему из рабочего состояния на часы и 
даже дни в тестовой лаборатории субподрядчика. Я наблюдал это в це- 
лом ряде проектов. 
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Я не против независимых лабораторий тестирования и консультан- 
тов. Во всяком случае, я один из них. Я не против дополнительных смен. 
Сам пользуюсь ими. Однако важно планировать тестирование с учетом 
того, что будут обнаружены проблемы. План тестирования, который 
предполагает, что все тесты пройдут без ошибок и что система будет хо- 
рошо работать, обречен на провал. Если вы планируете использование 
дополнительных смен и аутсорсинг тестирования с пониманием необхо- 
димости решать проблемы взаимодействия, поддержки и логистики, ко- 
торые возникают из-за сложного или полного ошибок продукта, эти вари- 
анты будут успешными. Кроме того, группа тестирования, которая 
увеличивает эффективность и производительность за счет использова- 
ния дополнительных смен и субподрядных групп тестирования, будет по- 
жинать хороший политический урожай за счет умения проводить более 
качественное тестирование в более короткие сроки. Доверие к ней будет 
расти. 


Учет праздников, отпусков и культурных традиций 


Периоды выполнения тестов — время наибольшего напряжения во мно- 
гих проектах — часто захватывают праздники. В самом деле, в разнообраз- 
ном смешении культур, присутствующем во многих компаниях всего 
мира, с большим трудом можно найти период, который не попадает на 
праздник для одного или нескольких сотрудников в проекте. 

Как продемонстрировал Джамал в нашем примере, культурное разли- 
чие внутри группы на самом деле является не слабостью, а преимущест- 
вом. В однородных проектах все хотят отдыхать в период одних и тех же 
праздников. В проектах с различием культур найдутся такие сотрудники, 
которые будут рады обменять, например, рождественские каникулы на 
их собственные культурные или религиозные праздники. 

Отпуска, если они не отгуливаются всеми одновременно, также пред- 
ставляют проблему с точки зрения вынужденного простоя, особенно для 
ключевых участников. Это может стать проблемой для короткого или 
очень рискованного проекта, и высшее руководство обычно отменяет все 
отпуска на этот период времени. Однако обычно кто-то берет отпуск в пе- 
риод длинного проекта. На самом деле, выбор невелик: либо предостав- 
лять отпуска, либо люди перестанут работать и начнут увольняться. 

Какой бы ни была причина отсутствия персонала, основным принци- 
пом является заблаговременное предупреждение. Я считаю, что это мож- 
но спланировать, зная об отпусках, культурных традициях и праздниках. 
В ходе проведения тестирования важно помнить, в какие недели будет ра- 
ботать сокращенное число сотрудников. Тест-менеджер может перене- 
сти часть тестирования на другие недели. 


Сбор данных о проекте тестирования на месте 


Сбор данных о проекте является особенно критичным, если есть внеш- 
ние зависимости. Если вы не сможете завершить плановое тестирование, 
поскольку не работает тестовая среда, в этом, возможно, не ваша вина. Ве- 
роятно, группа операций, ответственная за поддержку тестовой среды, 
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не отвечала на пейджинговые и телефонные запросы о помощи. Возмож- 
но, конфликт приоритетов не позволил им отреагировать на запросы 
так, как оговорено в плане тестирования. В этом случае руководство 
должно понимать, какое влияние конфликт приоритетов оказывает на 
тестирование. 

Конечно, может быть так, что внешние группы, от которых вы зависи- 
те, не заинтересованы в успехе тестирования или проекта в целом. По 
очевидным политическим причинам хранение точных протоколов в та- 
ких ситуациях - вопрос выживания. Обсуждение черной магии корпора- 
тивной политики находится за рамками этой книги. Скажу лишь, что для 
выхода из такого рода ситуаций понадобится адекватная документация. 


Внедрение усовершенствований 


Хотя проведение тестирования тесно связано с контекстом тестирова- 
ния и остального проекта, существует несколько идей, которые можно 
использовать во многих случаях для более успешного проведения тести- 
рования. 


1.Оцените, где вы находитесь и какие части процесса выполнения тес- 
тов, включая другие процессы, рассмотренные в этой книге, не на- 
ходятся под вашим контролем. Вероятно, некоторые из источни- 
ков хаоса являются внешними. Можете ли вы уменьшить влияние 
внешнего беспорядка на проект тестирования? 


2. Убедитесь в том, что вы знаете, как нужно проводить тестирование 
и сколько времени потребуется для выполнения выбранных тес- 
тов, разбитых на небольшие фрагменты. Двух-четырехчасовые за- 
дачи — это размер, которым, по моему мнению, удобно управлять. 
Они не обязательно должны принимать форму подробных тесто- 
вых сценариев, записанных в виде скриптов, когда можно оценить 
с точностью до минуты, сколько требуется в среднем на выполне- 
ние каждого детально описанного непротиворечивого шага. Впол- 
не достаточно увязать план тестирования (например, тестирова- 
ние возможностей манипуляции файлами) с планируемой 
продолжительностью (например, два часа на проверку возможно- 
стей манипуляции файлами). 


3. Используйте какой-либо способ отслеживания тестовых сценариев: 
таблицу тестовых сценариев, таблицу комплектов тестов (см. 
выше) или какой-то другой механизм, — сучетом как продолжитель- 
ности и сроков, так и результатов тестирования. Повторюсь, что 
вы можете начать с чего-то очень простого, и, возможно, этого бу- 
дет вполне достаточно. 


4. Используйте информацию о затратах на тестирование, которую вы 
собираете в процессе отслеживания тестовых сценариев, а также 
ваши прогнозы по поводу обнаружения ошибок в различные мо- 
менты фазы тестирования, чтобы предсказать, сколько времени 
нужно выделить на обработку ошибок. Классической ловушкой тес- 
тирования считается неспособность предвидеть наличие ошибок 
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в системе, предназначенной для тестирования. В результате плани- 

рования тестов так, будто они все успешно будут пройдены, обычно 
1 

недооцениваются затраты и время. 


5. Решайте вопросы, связанные с необходимостью внутреннего взаи- 
модействия и сбора информации. Многие проблемы тестирования 
возникают из-за того, что тестировщики не знают, что делают ря- 
дом их коллеги. 


Все эти шаги могут стать важными вехами на пути постановки под ваш 
контроль проведения тестирования. 

Компетентные тестировщики выполняют тесты дисциплинированно 
и с воображением, а компетентный тест-менеджер решительно и твердо 
управляет процессом выполнения тестов. Группа тестирования приспо- 
сабливается к неожиданным событиям и результатам тестирования и от- 
вечает на них, а также последовательно способствует росту стоимости 
компании. Во время выполнения тестов группа тестирования освещает 
путь проекту. 

Мы заканчиваем обсуждение фазы “Проведение” в процессе тестирова- 
ния. Умелое проведение тестирования создает актуальную, полную и точ- 
ную информацию о качестве системы. Это услуга и продукт, которые мы 
можем передать разработчикам, коллегам-менеджерам, менеджерам про- 
екта и даже высшему руководству. 

Передача этого продукта и оказание услуги дает возможность рабочей 
группе проекта совершенствовать систему. Кроме того, полученная ин- 
формация позволяет нам совершенствовать систему тестов. В заключи- 
тельных главах книги мы поговорим о подготовке отчетов о результатах 
тестирования, об управлении изменениями системы и, разумеется, об 
улучшение самого тестирования. 


№ этапа Этап Вьшолнено? 
З.А Проведение: выполнение тестов и сбор результатов м 
3.0 Получение и установка тестовой версии, состоящей из всех ы 
или нескольких компонентов системы, предназначенной для 
тестирования. 
ЗЕ Назначение ответственных за выполнение комплекта тестов М 


на каждой из тестовых версий, отслеживание комплекта и 
управление им. 


1 з 
Привычка планирования тестов с предположением, что они не пройдут успешно, на- 


столько прочно укоренилась в моем сознании, что я забыл упомянуть об этом в самом нача- 
ле. Я благодарен Тиму Коомену за то, что он указал на это упущение. 


Совершенствование 


о завершении проекта я ни разу не мог сказать: “Мы провели совер- 

шенное тестирование”. Но в каждом проекте я мог работать над со- 
вершенствованием тестирования, проводить тестирование лучше, чем в 
предыдущих проектах. Совершенство — это отличный стандарт, по кото- 
рому измеряются все наши достижения, поскольку мы намереваемся дви- 
гаться по направлению к совершенству, непрерывно становясь лучше. 

В заключительной части книги мы исследуем процессы управления со- 
вершенствованием разрабатываемой системы, а также самого процесса 
тестирования. Это происходит, помимо всего прочего, при помощи эф- 
фективного обмена информацией, в частности при помощи подготовки 
отчетов об ошибках и результатах тестирования. Мы можем использо- 
вать эту и другую информацию о процессах тестирования, чтобы сделать 
разумные изменения. 

В последней главе мы вновь рассмотрим весь процесс тестирования. 
Мы вернемся к большой картине, которую изучали в главе 1. Это поможет 
нам найти общие черты в качественных процессах тестирования и изучить 
способы решения основных проблем. Наконец, поскольку моя цель при на- 
писаний этой книги и ваша цель при ее чтении — найти способы улучшения 
процессов тестирования, мы завершим обсуждение этой темой. 


№ этапа Этап Выполнено? 
4. Совершенствование: предоставление информации о проекте а 
и его улучшение. 
4.А. Документирование ошибок, обнаруженных в ходе выполне- а 
ния тестов. 
4. В Обсуждение результатов тестирования с ключевыми заинте- а 
ресованньми лицами. 


4.С Управление изменениями и уточнение процесса тестирования. а 


ГЛАВА 14 


Когда качество не оправдывает 
ожиданий: подготовка отчетов 
06 ошибках 


В этой главе рассматривается процесс составления отчетов об ошиб- 
ках. В известном смысле отчеты об ошибках — это основной матери- 
альный продукт тестирования, надежная техническая документация, ко- 
торая описывает вид ошибки в тестируемой системе, который может 
повлиять на мнение пользователя о системе!. Каждый отчет об ошибке 
должен предоставлять руководству информацию, необходимую для при- 
нятия решения по приоритету ошибки. Для тех ошибок, которые счита- 
ются заслуживающими исправления, каждый отчет об ошибке должен 
предоставлять программисту всю необходимую для исправления этой 
ошибки информацию. 

Подготовка отчетов — это процесс тестирования, удовлетворяющий 
всем четырем критериям, которые я сформулировал во введении, когда 
отбирал ключевые процессы. Это процесс, в который мы вовлечены в 
ходе выполнения тестов каждый день, а иногда много раз в день. Отчеты 
об ошибках читают программисты, а также руководители разных уров- 
ней, вплоть до высшего. Если процесс подготовки отчетов об ошибках 
осуществляется правильно и сами отчеты готовятся верно, в результате 
внутри группы тестирования организуется командная работа, а также 
возрастает доверие к группе тестирования среди сотрудников рабочей 
группы проекта. Хорошо подготовленные отчеты об ошибках, распреде- 
ленные по приоритетам руководством и исправленные программистами, 
являются движущей силой, при помощи которой группа тестирования 
оказывает влияние на рост качества системы, в то время как плохие отче- 


1 Вто же время, как напомнил мне Рик Крейг, прочитав эту главу, в некоторых случаях 


“сами тестовые сценарии могут стать частью документации программного продукта. По 
мере того как система стареет и спецификации требований и/или архитектуры [или сами 
требования и/или архитектура] устаревают, возрастает вероятность того, что документа- 
ция, описывающая, что система обязана делать, содержится только в тестовых сценариях”. 
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ты об ошибках могут привести к тому, что опасные дефекты останутся 
в системе, переданной в эксплуатацию. Каждый тестировщик в группе 
тестирования должен владеть этим процессом, чтобы вносить макси- 
мально возможный вклад в разработку. 


Процесс подготовки отчетов об ошибках 


Как составлять наилучшие отчеты об ошибках? Процесс 10 представляет 
собой процесс подготовки отчетов об ошибках, которые я применяю в 
большинстве своих проектов?. 


Процесс 10. Процесс подготовки отчетов об ошибках 


№ этапа Этап Выполнено? 

1. Выполнить каждый тест, используя надежные структуриро- О 
ванные методы тестирования. 

2; Воспроизвести любые отклонения от ожидаемого поведения. О 

3. Локализовать ошибку, проверив действие основных вариан- О 


тов, а также исследуя возможные обходные пути. 


4. Найти, по возможности, общий случай, наиболее серьезный а 
или наименее желательный. 


5. Сравнить наблюдаемое неправильное поведение с поведени- О 
ем системы при похожих условиях или в предыдущих тесто- 
вых версиях. 


6. Обобщить сведения об отказе, включая его воздействие на за- О 
казчиков и пользователей. 


7. Сократить отчет, удалив ненужную информацию. о 


1 Части этой главы были ранее опубликованы в " Рио/йззіопа! Теяе?”. Я благодарен Кэролайн 


Квентин (Сагоіпе Оцеп п) за ее отличную работу по редактированию той статьи. Некото- 
рые фрагменты этой главы также были напечатаны в книге Эрика Ван Веенендааля (Егікуап 
Уеепепдаа!) “Тйе Тезйтр Ргасійіопет". Я благодарю его за включение этого важного процесса 
в качестве части признаваемого отраслью подхода к обработке ошибок в программах. 


2 Яизвлек пользу изонлайновой дискуссии с Бретом Петтикордом, состоявшейся в 1999 году, 
по поводу этой таблицы. Я благодарю его за вклад в мои рассуждения на эту тему. 
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Процесс 10 (продолжение) 


№ этапа Этап Выполнено? 

8. Устранить противоречия, удалив сбивающие с толку, вводя: о 
щие в заблуждение или неточные слова. 

9. Подготовить нейтральный отчет об ошибке, выражая мысли а 
беспристрастно и спокойно. 

10. Передать отчет об ошибке на перекрестноє рецензированиє, О 


разрешить проблемы, если они обнаружены, и затем ввести 
отчет в систему управления дефектами. 


Поскольку этот процесс критически важен, поясню влияние каждого 
из этапов на проект. 


1. 


1 


Структура. Подготовка полезного отчета об ошибке начинается с 
надежного, хорошо организованного тестирования. Тестирование 
может быть ручным и автоматизированным, вестись по плану или 
быть исследовательским, но оно должно отличаться от простых ха- 
керских бесцельных попыток сломать продукт. Небрежное тести- 
рование приводит к небрежным отчетам об ошибках. 


Воспроизведение. Ошибки, конечно, часто застают меня врасплох! 
Если бы я мог предугадать заранее, когда я найду ошибку, мне не 
нужно было бы тестировать систему. Воспроизведение проблемы 
обостряет мое понимание вопроса и позволяет жестко зафиксиро- 
вать последовательность шагов, которые заново приведут к отказу. 
В качестве эмпирического правила я предпочитаю делать три по- 
пытки. Время от времени появляются ошибки, которые не всегда 
воспроизводятся и с большим трудом поддаются исправлению. 
Я информирую о таких ошибках с пометкой об их нерегулярности, 
например: “эта ошибка проявилась в двух из трех попыток” 


Локализация. На поведение программы могут влиять многие факто- 
ры, анекоторые из этих факторов воздействуют на симптомы ошиб- 
ки. Часто большое значение имеет способ, при помощи которого из- 
менение в тестовой среде обнаруживает само себя с точки зрения 
поведения ошибки. Изменяя некоторые важные переменные, каж- 
дый раз по одной, в попытке изменить поведение ошибки, я вижу, 
что могу написать более точный отчет об ошибке. Локализация 
ошибки --непростая задача. До некоторой степени я должен понять, 
как работает система, предназначенная для тестирования. Я должен 
продумывать тесты, прежде чем выполнять их. Я также избегаю по- 
гружения в отладку и трат неразумного количества времени на три- 
виальные случаи. Однако точная локализация ошибки способствует 
росту доверия тестировщику и дает программисту преимущество 
при отладке. Кроме того, я могу найти доступный и полезный обход- 
ной путь как часть локализации ошибки (см. главу 3). 


Стив Сплэйн, один из рецензентов этой книги, рассказал мне, что при обнаружении не- 


регулярно возникающей ошибки он “обычно включает дополнительную информацию 
о конфигурации [системы]... поскольку есть вероятность, что причины [ошибки] связаны 
с несовместимостью... 
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Обобщение. Часто симптом, который я вижу при первом обнаруже- 
нии ошибки, не является наиболее общим случаем. Например, не- 
давно я нашел проблему, при которой программа не импортирова- 
ла особый вид таблицы из файла в формате Ехсе!. Когда я копнул 
чуть глубже, я понял, что невозможно импортировать таблицу из 
любого файла в формате Ехсеї, если имя таблицы содержит круглые 
скобки. Важно при поиске общего случая не доходить до абсурда. 
Не все отказы программы происходят из-за одной и той же ошибки. 
Тем не менее, попытка найти общее правило возникновения ошиб- 
ки углубляет мое представление о системе и позволяет убедить про- 
граммистов и менеджеров в том, что проблема не является единич- 
ным случаем. | 


Сравнение. Тестирование часто покрывает одну и ту же область, 
и когда тестировщик выполняет одни и те же тесты в разных верси- 
ях системы, и когда тестировщик выполняет тесты, чтобы покрыть 
похожие условия. Полученные результаты могут дать программи- 
сту разгадку, если мне удастся соединить концы с концами. Являет- 
ся ли отказ регрессией? Работает ли то же свойство в других частях 
продукта? Хотя такой способ исследования не всегда возможен, на- 
пример, если тест был заблокирован в предыдущей версии, он по- 
зволяет программисту сэкономить массу времени. 


Краткое описание. В этот момент я, по всей вероятности, понимаю 
проблему в программе достаточно хорошо, чтобы увидеть, как она 
повлияет на заказчиков или пользователей. В качестве части про- 
цессов управления изменениями и разбора дефектов (см. главу 16) 
важно рассмотреть бизнес-риски, относящиеся к каждой ошибке, 
как элемент принятия решения об обязательности их исправления. 
Полезный отчет об ошибке включает в себя краткое описание, ко- 
торое показывает суть и значение проблемы группе по управлению 
изменениями или комиссии по разбору ошибок. (Поле для кратко- 
го описания может носить названия “Заголовок”, “Краткое содер- 
жание”, “Описание воздействия” и т.п., но смысл в том, что это 
краткое, в одном предложении, выражение содержания всего отче- 
та.) Краткое описание становится неоценимым, когда наступает 
время расстановки приоритетов ошибок. Оно также служит назва- 
нием ошибки для программистов. “Ты уже исправил ошибку со 
шрифтами? — вопрос, который вы можете задать программисту, бу- 
дет, наверное, более понятным, чем вопрос “Как продвигается ра- 
бота над ошибкой 1716?” Подготовка полезного краткого описания 
гораздо труднее, чем кажется. Математик Блэз Паскаль однажды за- 
вершил длинное письмо фразой: “Я написал бы более короткое 
письмо, но у меня на него не было времени”. Я потратил много вре- 
мени на подготовку полезных кратких описаний, поскольку это 
наиболее важные предложения в отчетах об ошибках. 


Уменьшение объема. К слову о написании более коротких писем, поду- 
майте, нельзя ли удалить некоторые ненужные слова из отчетов об 
ошибках? Однажды я читал отчет об ошибке, первая страница кото- 
рого была посвящена описанию того, как тестировщик набрал мно- 
го очков при игре в тетрис, что не имело ничего общего с пробле- 
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мой. Разве меня волновало это достижение тестировщика? Нет. 
Должен ли я был тратить время на чтение этого? Нет. Вызвал ли 
тестировщик, написавший этот отчет, внимание к его последую- 
щим отчетам? Тоже нет. Лучшие отчеты об ошибках не являются 
ни загадочными комментариями, ни занудными, бесконечными и 
бесцельными документами. Я стараюсь пользоваться только теми 
словами, которые мне нужны, описываю только последователь- 
ность действий и даю информацию, действительно имеющую отно- 
шение к ошибке, по которой готовится отчет. 


Устранение противоречий. Устранить противоречия означает уда- 
лить сбивающие с толку или вводящие в заблуждение слова, кото- 
рые могут озадачить читателя и не позволят ему понять, что имеет- 
ся в виду. Идеальный отчет об ошибке подводит программиста к 
ошибке за руку. Например, что подразумевается, если написано: 
“Программа прекратила работу”. Она перестала отвечать, но оста- 
лась на экране? Удалось ли штатно выйти из нее? Или она заверши- 
лась внештатно? Она завершилась и закрыла одну или несколько 
программ? Она завершилась и вызвала фатальную ошибку в опера- 
ционной системе? Слова “Программа прекратила работу” неодно- 
значны, подобного не должно быть в отчетах об ошибках. Яс- 
ность — вот ключ к решению проблемы". 


Нейтральность. Как гонец с плохими новостями, я должен выра- 
жать свои мысли в отчете об ошибке спокойно и беспристрастно. 
Атака на программиста, критика ошибки в коде, юмор или сарказм 
в отчете об ошибке обычно приводит к бурной ответной реакции. 
Я стараюсь проявлять деликатность и ясность мысли в описании 
ошибки и ее последствий, ограничиваю свои отчеты констатацией 
факта и не занимаюсь предположениями и преувеличениями. От- 
четы об ошибках после того, как их занесли в систему управления 
дефектами, обычно остаются там навсегда и могут быть прочитаны 
людьми, не участвующими в проекте". 


Рецензирование. Как упоминалось ранее, отчет об ошибке — это тех- 
нический документ. Экспертные оценки, инспекции, быстрые про- 
смотры и т.п. — это мощные инструменты для раннего обнаружения 
проблем в документах любых видов, включая отчеты об ошибках. 
Если вы хотите пропустить этот этап как слишком затратный по 
времени или как ненужный контрольный пункт, чтобы побыстрее 
ввести отчет об ошибке в систему управления дефектами, подумай- 
те о задержках и возможном срыве планов, которые могут произой- 
ти, если программист потратит много времени на воспроизведе- 


1 я получил немалую пользу от некоторых комментариев Джоанны Ротман по поводу уст- 
ранения противоречий, благодарю ее за содержательные замечания. 


2 Этопохожена то, о чем писал Сем Канер в“ Тестировании программного обеспечения”. Нико- 
гда неизвестно, кто будет читать ваши отчеты об ошибках (возможно, адвокат истца?), по- 
этому следует избегать ненужных слов, которые могут стать свидетельством для наказания 
вашего работодателя, нужно писать только в точности то, что вы имеете в виду. Однажды 
я действительно был вынужден работать вместе с адвокатом, когда имела место попытка на 
основе анализа отчетов об ошибках выдвинуть обвинения против группы разработки. 
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ние ошибки, которая на самом деле является ошибкой в тесте, или 
если программист не может понять, о чем этот отчет, и возвращает 
ошибку как “невоспроизводимую” или “работающую, как спроекти- 
ровано”. Рецензирование не должно быть формальным. Я добивал- 
ся успеха, когда одним из требований к рецензированию было про- 
чтение одним тестировщиком отчетов другого перед отправкой 
отчета об ошибке в систему управления дефектами. 


Позвольте мне указать на два общих наблюдения по поводу процесса 
перед тем, как мы пойдем дальше. Во-первых, важно помнить, что написа- 
ние отчетов является творчеством: два полезных отчета об ошибке по од- 
ной проблеме могут отличаться и по стилю, и по содержанию. Цель про- 
цесса подготовки отчетов об ошибках — не стандартизовать сами отчеты, 
а обеспечить их качество. Во- вторых, этот процесс работает наилучшим 
образом, когда он воспринимается как список контрольных вопросов, 
а не строгий последовательный процесс. Первый и последний этапы, 
структурированное тестирование и перекрестный просмотр, являются 
логическими точками начала и завершения, но если вы чувствуете себя 
более комфортно, когда ваш текст нейтрален, делайте именно так. 


Большая ошибка в большой сборке 


В понедельник 16 декабря Луис тестировал большую сборку для проверки 
функциональности управляемых файлов. Он создал новый файл и ввел 
текст. Затем он попытался изменить шрифт текста: выделил текст, вы- 
звал меню шрифтов и выбрал шрифт Зупрої. Неожиданно там, где только 
что было нормальное предложение наанглийском языке, появился набор 
символов, вопросительных знаков и других бессмысленных значков. 
“Хм, — задумался Луис, — это явно не из категории “приемлемого поведе- 
ния”. Он начал подготовку отчета об ошибке, сделав пометки в своем 
блокноте. 


№ этапа Этап Выполнено? 
1. Выполнить каждый тест, используя надежные структуриро- 


ванные методы тестирования. 


Возможно, так Луис описал бы проблему в разговоре с тест-менедже- 
ром Джамалом Брауном в тестовой лаборатории, но он не мог предста- 
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вить ее в таком виде программисту, менеджеру разработки или менедже- 
ру проекта. Учитывая этих потенциальных читателей отчета, Луис 
вернулся к системе и воспроизвел проблему еще два раза. Затем он начал 
вводить отчет в базу управления дефектами. 


№ этапа Этап Зыполнено? 


2. Воспроизвести любые отклонения от ожидаемого поведения. м 


Описание проблемы стало выглядеть лучше. Программист мог прочи- 
тать и быстро приступить к отладке проблемы. Однако Луис знал, что 
продукт 5Зреедууутігег, как и любое другое приложение, поддерживает ши- 
рокий диапазон свойств и конфигураций, которые могут повлиять на по- 
ведение этой ошибки. Поэтому Луис провел несколько экспериментов в 
поисках обходных путей. Затем он добавил следующий раздел в отчет. 


№ этапа Этап Выполнено? 


3. Локализовать ошибку, проверив действие основных вариан- М 
тов, а также исследуя возможные обходные пути. 


Это был особый вид ошибки, поэтому Луис решил проверить и не- 
сколько других шрифтов и выяснить, оказывают ли какое-то влияние 
шрифты, стили шрифтов и определенный текст на ошибку. Он обнару- 
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жил, что шрифты У/іпрдіпоз и Ана! также вызывают проблему. Поскольку 
пользователи 5рееду\Мтиег активно применяют шрифты Ана|, последнее 
было существенным. Однако эксперименты с полужирным, курсивом и 
подчеркнутым вариантами шрифтов не повлияли на проявление ошибки. 
Луис выяснил, что определенные строки текста и количество текста ни- 
как не влияют на ошибку. Он удалил потенциально вводящую в заблужде- 
ние ссылку на стили шрифтов и текстовую строку из шага 2 отчета и изме- 
нил отчет следующим образом (см. части, выделенные курсивом), чтобы 
дополнительно обозначить связь ошибки со шрифтом Агіа! (и исправить 
грамматическую ошибку). 


№ этапа Этап Выполнено? 


4. Найти, по возможности, общий случай, наиболее серьезный 
или наименее желательный. 


Далее Луис просмотрел протоколы тестирования предыдущих тесто- 
вых циклов комплексного и системного тестирования и изучил некото- 
рые отчеты о тестировании, подготовленные программистами на фазе 
компонентного тестирования. Он обнаружил, что именно это свойство 
проверялось, что натолкнуло его на мысль, что эта проблема является 
ошибкой регрессии в качестве системы. Он добавил соответствующую 
строку в раздел “Локализация ошибки”. 


и (3:1: `В). тотжете 
07.ТЕ и 3.1.0 ЛВ. 
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№ этапа Этап Выполнено? 
5. Сравнить наблюдаемое неправильное поведение с поведени- м 

ем системы при похожих условиях или в предыдущих тесто- 

вых версиях. 


Теперь Луис четко понимал суть ошибки, как она себя будет проявлять 
и как она повлияет на пользователя. Он вписал в отчет следующую строку 
с кратким описанием ошибки. 


№ этапа Этап Выполнено? 
6. Обобщить сведения об отказе, включая его воздействие на за- 
казчиков и пользователей. 


Итак, Луис зафиксировал влияние ошибки на пользователя и основ- 
ную природу проблемы в восьми словах. Он уверен, что любой из прочи- 
тавших его краткое описание ошибки поймет, в чем проблема и почему 
она важна. 

Отчет об ошибке подготовлен. Все, что осталось, — потратить немно- 
го времени на наведение глянца. Сначала Луис немного ужал отчет, уда- 
лив лищние слова. Например, предложение: 


он записал так: 


Он также удалил слово “я” из раздела “Шаги для воспроизведения”. 


№ этапа Этап Выполнено? 


7. Сократить отчет, удалив ненужную информацию. М 
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Далее Луис проверил отчет на наличие противоречивых или запуты- 
вающих смысл предложений, которые могут смутить читателя. Он изме- 
нил шаг 3с 


на 


Шаг 4 изменился с 


В разделе “Локализация ошибки” он изменил 


Глава 14. Когда качество не оправдывает ожиданий 405 


Наконец, в строчку раздела “Локализация ошибки”, которая звучала 
как: 


Луис добавил: 


№ этапа Этап Выполнено? 
8. Устранить противоречия, удалив сбивающие с толку, вводя- 


щие в заблуждение или неточные слова. 


В завершение Луис освободил отчет от всех ярких суждений и при- 
страстных комментариев, которые могут встревожить или отвлечь чита- 
телей. Он решил, что шаг 4 слишком резкий, поэтому изменил формули- 
ровку следующим образом. 


есьтекст превратился вуправляющие символы, цифрыи 
ные, двоичные данные 


№ этапа Этап Выполнено? 
9. Подготовить нейтральный отчет об ошибке, выражая мысли 


беспристрастно и спокойно. 


Наконец, Луис попросил Лин Цу проверить отчет. 

“Выглядит очень неплохо, Луис - сказала Лин Цу. — Хотя один вопрос. 
Эта ошибка имеет какое-либо отношение к проблеме создания файлов, 
которую ты нашел в предыдущем тестовом цикле? 

“Не думаю, — ответил он, — поскольку эта ошибка имеет отношение к 
конкретным шрифтам. Предыдущая ошибка была связана с конкретными 
типами файлов”. 

“Хорошо, — ответила она. — Только одно предложение. Я бы хотела 
удалить слово “мусор” из раздела “Локализация ошибок”. Оно неудачно”. 
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“ОЙ, я просто упустил это, —улыбнулся Луис. — Я сначала говорил ому- 
соре на протяжении всего отчета, но потом удалил его отовсюду, кроме 


этого раздела. Извини”. 
“Ничего страшного, для этого мы и просматриваем отчеты друг дру- 


га, — успокоила его Лин Цу. 


№ этапа Этап Выполнено? 


10. Передать отчет об ошибке на перекрестное рецензирование, м 
разрешить проблемы, если они обнаружены, и затем ввести 
отчет в систему управления дефектами. 


Это надежное описание ошибки, обнаруженной Луисом. Оно инфор- 
мирует о проблеме, способствует принятию решения руководством о не- 
обходимости исправления ошибки на основе ее влияния на заказчика. 
Оно также дает группе разработке неплохое руководство для работ по 
отладке. 
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За рамками описания дефекта 


Помимо описания дефекта, системы управления дефектами должны по- 
лучать некоторые дополнительные сведения, чтобы весь процесс управ- 
ления дефектами был работоспособным. Два из них — это серьезность 
и приоритет. 

Под серьезностью я понимаю техническое влияние на систему, пред- 
назначенную для тестирования, глубину воздействия ошибок. Я часто ис- 
пользую следующую шкалу для измерения серьезности. 


1. Потеря данных. Ошибка вызывает потерю данных пользователя (ко- 
нечного пользователя, оператора и т.п.) или системы. 


2. Потеря функциональности. Ошибка блокирует использование важ- 
ной функциональной области (может включать в себя нефункцио- 
нальные проблемы, в частности проблемы производительности, 
которые приводят к неприемлемым задержкам в выполнении функ- 
ций). 

3. Потеря функциональности с наличием обходных путей. Ошибка блоки- 


рует применение основной функциональной области, но для поль- 
зователя существует разумный обходной путь. 


4. Частичная потеря функциональности. Ошибка препятствует использо- 
ванию некоторой несущественной части функциональной области, 


5. Косметическая ошибка. Ошибка позволяет функциям нормально ра- 
ботать, но с существенными недостатками (особенно в пользова- 
тельском интерфейсе или в способности системы реагировать на 
запросы)". [номер сноски 7] 


Под приоритетом я понимаю значимость устранения проблемы, что 
в некоторых случаях является сложным бизнес-решением. На него могут 
воздействовать следующие факторы: влияние ошибки на проект и на ве- 
роятный успех продукта на рынке, зависимости между ошибками и/или 
тестами, требования инструкций, стандартов или контракта, а также 
серьезность ошибки. Я часто пользуюсь следующей шкалой приоритетов. 


1. Срочно. Ошибка требует немедленного исправления. 
2. Важно. Ошибка должна быть исправлена в этой версии. 


3. Значимо. Ошибка может существенно снизить ценность системы 
хотя бы для одного из заказчиков или пользователей. 


4. Желательно. Ошибка должна быть исправлена в этой версии, если 
это возможно в условиях ограничения свойств, бюджета и сроков, 
в противном случае - в ближайшей очередной версии. 


5. На усмотрение. Ошибка может быть исправлена в одной из будущих 
версий, если позволяют другие приоритеты. 


1 Эта шкала позаимствована из стандарта 2167А министерства обороны США для тестиро- 


вания. Существует большое число других вариантов классификации серьезности. Посмот- 
рите статью Тима Дайеса (Тип Гуез) “Тгаскіпр Зеуегіїу" в Зо/їшате Тейте апа Фиайу 
Епоіпееттр, Уоіате 1, 155ие 2 (Маг/Арг 1999), доступную в настоящее время на 
умуг.50іскутіпадѕ.сотп. 
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Серьезность и приоритет — отличные друг от друга понятия, причем 
приоритет является более важным из них. Процесс расстановки приори- 
тетов ошибок обсуждается в главе 16, сейчас же позвольте мне кратко 
объяснить разницу. | 

Поверхностный взгляд приводит некоторых инженеров-программи- 
стов и системщиков, включая тестировщиков, к выводу, что чем выше 
серьезность ошибки, тем выше ее приоритет, и наоборот. Это не всегда 
так. Представим, что ошибка вызывает появления на экране неверного 
сообщения. Это серьезность 5 по моей шкале. А что, если неверное сооб- 
щение содержит оскорбительное, непристойное или расистское слово? 
Если не драматизировать, то предположим, что на всплывающем экране 
неверно отображается название продукта. Эти виды проблем являются 
обязательными для исправления в текущей версии независимо от серьез- 
ности. 

И наоборот, ошибка потери данных, которая проявляется только при 
определенных несущественных обстоятельствах в маловероятной и уста- 
ревшей конфигурации, может иметь серьезность 1, но приоритет 5 в рам- 
ках моего определения. Что, если редактор 5реедууУ/тіег теряет данные, 
если мы сохраняем их на дискете размером 5.25 дюйма и емкостью 
360 Кбайт? Вероятно, что вместо исправления ошибки в программе мы 
должны просто зафиксировать в документации, что наш продукт не под- 
держивает такие дисководы . 

Важной для отчета об ошибке является информация о прошедшей тес- 
тирование версии продукта. В нашем примере Луис пишет отчет об ошиб- 
ке в сборке 3.1.018.ТК и замечает, что все сборки от 3.1.007.ТК до 
3.1.017.ТВ не имели такой ошибки. Для того чтобы зафиксировать эту ин- 
формацию, необходимо держать под контролем процесс подготовки тес- 
товых версий (см. главу 12). 

В интегрированных системах управления тестированием, когда репо- 
зитории ошибок и тестов находятся в одной базе данных, эти два репози- 
тория могут быть связаны друг с другом. Результаты тестовых сценариев 
могут быть привязаны к определенным отчетам об ошибках, а отчеты об 
ошибках могут быть сопоставлены тестовым сценариям. Возможность от- 
слеживания полезна как для тестировщиков, так и для программистов. 
Если база данных управления дефектами не поддерживает этого свойст- 
ва, я добавляю в процесс ввод номера теста в описание дефекта. 

Если говорить о возможности отслеживания, некоторые ошибки мо- 
гут быть привязаны к определенным требованиям, бизнес-правилам, 
сценариям использования системы или рискам качества. В главе 15 бу- 
дет показано, как при помощи отслеживания результатов тестирования 
ЅрееауМгігег и отчетов о дефектах тестировщик может говорить о де- 
фектах в терминах оценки качества системы и рисков. Итак, удобные 
системы управления дефектами обеспечивают поддержку такого отсле- 
живания. Если нет, то я добавляю в процесс еще один этап, который 
включает в себя ввод тестировщиком этой информации в описание де- 
фекта. 


1 Вкниге "бо/їшате Тейт; Тесйтйдиез” Борис Бейзер приводит интересное обсуждение оши- 


бок и того, что он называет “значимость ошибки”. 
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Поскольку ошибки могут зависеть от конкретной тестовой конфигура- 
ции, тестировщики должны выработать привычку фиксировать и это. 
Привязка к конкретной тестовой конфигурации также может быть либо 
встроенной в системууправления дефектами (за счет просмотра таблицы 
конфигураций), либо зафиксирована как часть описания дефекта. 

Еще одна часть информации, которую полезно фиксировать, это за- 
тронутая подсистема, компонент или функция. Например, для текстово- 
го процессора я использую следующие категории: 


и Пользовательский интерфейс 

и Движок редактирования 

и Операции с файлами 

Режимы установки и варианты конфигураций 
Документация и пакетирование 

Прочее 

Неизвестное 


Нет данных 


Полезно собирать информацию для различных метрик, включая улуч- 
шение текущего и будущего тестирования, чтобы направить усилия на те 
области продукта, которые демонстрируют наибольшие проблемы. 

В типичной системе отслеживания дефектов программист, который 
исправляет ошибки, и, возможно, инженер сборок, который интегриру- 
ет исправленный код в репозиторий кода, будут заполнять ряд полей. Эти 
поля обычно не оказывают большого влияния на группу тестирования, за 
исключением информации о том, какая сборка содержит исправление 
кода, связанное с данной ошибкой. Тестировщики, возможно, сочтут по- 
лезными отчеты на основе этой информации при подготовке к провероч- 
ному тестированию исправлений ошибок в данной тестовой версии. 

Наконец, хочу отметить модели устранения дефектов и данные, кото- 
рые может собирать база данных управления дефектами для поддержки 
этих моделей. Модели устранения дефектов позволяют нам отслеживать, 
когда дефект попал в систему, когда был найден и когда был исправлен. 
(Обычно эти события называются вводом дефекта, обнаружением дефекта 
и удалением дефекта соответственно.) Как тестировщики, мы знаем, когда 
мы нашли дефект и когда его устранили, но нам нужна помощь програм- 
мистов для того, чтобы отследить, когда каждый дефект попал в систему. 

Я использовал здесь слово “когда”, но часто модели устранения дефек- 
тов заинтересованы не столько в конкретных датах или времени, сколько 
в фазах проекта. Поэтому сбор данных для типичной модели устранения 
дефектов может означать, что отчеты об ошибке имеют поля для фикса- 
ции фаз ввода, обнаружения иудаления, каждая из которых заполняется в 
определенный момент. Поле может заполняться из списка для выбора, 
содержащего типичные фазы: требования, архитектура, реализация, 
компонентное тестирование, комплексное тестирование, системное тес- 
тирование, приемо-сдаточные испытания и эксплуатация. В модели ин- 
крементного или итерационного жизненного цикла можно также отсле- 
живать номер инкремента или итерации. 
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Эти данные полезно занести в репозитории проекта, а также исполь- 
зовать в качестве способа усовершенствования процесса. Имея репозито- 
рий проектных данных, мы можем постепенно выстроить модель устра- 
нения дефектов, которая позволит оценить, сколько ошибок будет 
в каждой разрабатываемой системе и когда мы их обнаружим. Эта цель 
обозначена в главе 3. 

Как только мы получаем достаточно данных для подготовки точных 
прогнозов об ошибках и фазах, на которых мы вносим, находим и исправ- 
ляем дефекты, мы можем попытаться улучшить процесс. Мы можем уста- 
новить цели для обнаружения и устранения дефектов до завершения каж- 
дой фазы проекта в предположении, что мы можем предсказать число 
ошибок, которые мы внесем в систему. Ошибки менее опасны и дороги 
для проекта, если они обнаруживаются и устраняются на той же фазе, на 
которой внесены, поскольку они не порождают других ошибок. Согласно 
терминологии устранения ошибок, обнаружение и устранение всех оши- 
бок, внесенных в ходе каждой фазы проекта, будет означать, что процент 
потери ошибок равен 0%. 


Построение успешного процесса подготовки 
отчетов об ошибках 


Итак, чего же достигают группы тестирования и рабочие группы проектов 
за счет применения удобного процесса подготовки отчетов об ошибках? 


Эффективная передача полезной информации 


Как было показано в главе 13, тестирование создает информацию, полез- 
ную как для внутреннего (в рамках группы тестирования), так и для внеш- 
него (для всей группы проекта или даже компании) употребления. Основ- 
ной формой передачи информации являются отчеты об ошибках. Для 
внешнего окружения отчеты об ошибках являются частью информации о 
качестве, которой тестировщики снабжают проект, включая процесс 
управления изменениями (см. главу 16). Для того чтобы быть действенны- 
ми, отчеты об ошибках должны предоставлять программистам сведения, 
необходимые для исправления важных ошибок. Все вместе отчеты об 
ошибках являются основой для измерения всего проекта (см. главу 15). 

Что касается внутреннего употребления, каждая ошибка позволяет 
тестировщику лучше понять природу и качество системы, которую он тес- 
тирует. (Вспомните примеры, как положительные, так и отрицательные, 
из нашего примера в главе 13.) Вновь повторюсь, что ошибки, обнаружен- 
ные в ходе выполнения предыдущих тестов, дают информацию для даль- 
нейшего тестирования и для понимания ошибок, обнаруживаемых при 
выполнении последующих тестов. 


1 сы. “Мася ата Моде т Зо/їшсте Оиа у Епріпеетіпр, Зесопа Еайіоп'" Стефана Канна и “СММ 


іп Ргасйсе” Панкоджа Джалота. Более простое изложение темы представлено в "Матаріпеє іће 
Теяйте Ргосеѕѕеѕ, 5есопа Еаййоп". 
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Какую информацию должны предоставлять тестировщики, помимо 
понятных описаний дефектов, комментариев и классификации дефек- 
тов, чтобы помочь программистам исправить ошибки? Эта информация 
может существенно отличаться в разных проектах. Однако я бы предло- 
жил несколько идей. 


и История тестирования. Пока вы не перезагрузили всю сеть, в кото- 
рой выполняете тесты, всегда существует вероятность того, что ра- 
нее выполненные тесты могут повлиять на поведение обнаружен- 
ного дефекта. Например, в проекте по разработке Интернет- 
приложения мы вынуждены были отслеживать, какие виды сбоев 
соединения происходят во время тестирования на каждом устрой- 
стве, и отмечали это в каждом отчете об ошибке. Логика заключает- 
ся втом, что компьютер — это в первую очередь конечный автомат. 
Любая совокупность действий, пока не будет выполнена переза- 
грузка, переводит память, процессор, накопители на жестких дис- 
ках и другие компоненты в определенное состояние, которое мо- 
жет повлиять на выполнение последующих действий. Сеть 
компьютеров — это также конечный автомат, и информация о со- 
стоянии одного компьютера может повлиять на работу других ком- 
пьютеров. Информация, которую можно фиксировать в этом отно- 
шении, практически бесконечна. Поэтому с практической точки 
зрения большинство групп тестирования, которые фиксируют ис- 
торию тестирования в отчетах об ошибках, документируют выпол- 
нение тестовых сценариев в системе, предназначенной для тести- 
рования, до того, как была обнаружена ошибка, а также все другие 
ошибки, которые были найдены в системе до обнаружения данной 
ошибки. 


ш Фиксация экранов (снимки экранов) и даже видеоклипы. Некоторые 
операционные системы и большинство инструментов тестирова- 
ния на основе графического пользовательского интерфейса дают 
возможность тестировщикам фиксировать вид экрана рабочей 
станции. Полученные картинки могут быть ценнее 10 000 слов в 
оказании помощи программистам. 


= Цифровые снимки. Наличие цифровой камеры в тестовой лабора- 
тории позволит вам получать снимки экрана или системы после об- 
наружения ошибки. Фиксация экранов при помощи средств рабо- 
чей станции удобна, но она невозможна, если система терпит крах. 
Кроме того, если вы тестируете аппаратные средства, сбои могут 
иметь физический характер. Трудно описать, что произошло, ко- 
гда ломается болт или корпус компьютера, а снимок сделает это по- 
нятным. 


и Содержимое памяти (дамп памяти). Некоторые системы могут 
быть сконфигурированы таким образом, что если система обнару- 
жит ошибку внутри себя, она сохранит содержимое памяти цели- 
ком, включая регистры, в специальном файле. На языке ОМІХ 
и универсальных машин этот файл называется “дамп памяти”. Мно- 
гие конфигурации интегрированных тестовых сред позволяют” 
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программистам просматривать дампы памяти в поисках ответов на 
вопрос, что случилось, когда в системе произошел сбой. 


= Информация о внутренней трассировке. На ранних фазах тестиро- 
вания при обнаружении большого числа ошибок, особенно если 
есть ошибки, воспроизводимые не каждый раз, можно попросить 
программистов и инженеров сборки передать то, что иногда назы- 
вают отладочной сборкой. В качестве альтернативы можно инстру- 
ментировать сборку, чтобы фиксировать информацию, которая 
может сообщить нам, какие выполняются операторы системы, ко- 
гда происходит ошибка. Еще один вариант — сборка может содер- 
жать специальные операторы вывода, которые протоколируют 
внугреннюю информацию. Здесь нужно сделать одно замечание. 
При использовании отладочных сборок для тестирования я пре- 
кращаю принимать такие сборки на тестирование с началом фазы 
системного тестирования. Мне нужно время для выполнения боль- 
шинства моих тестов хотя бы однажды в сборке, не являющейся от- 
ладочной. Инструментирование, отладочные протоколирующие 
операторы и другой код, который не будет поставляться с систе- 
мой, могут замаскировать или изменить поведение ошибок. 


= Рабочие файлы (вспомогательные файлы). Некоторые системы соз- 
дают рабочие файлы в ходе своей работы. Эти файлы часто разме- 
щаются в особых каталогах и имеют имена определенного форма- 
та. (Например, приложения М!сгозой ОЁйсе часто создают файлы с 
расширением {тр в текущем рабочем каталоге.) Если тестировщи- 
ки знают, где находятся такие файлы и как они называются, они мо- 
гутприсоединить эти файлы к отчету об ошибке или сохранить их в 
специальном месте. 


= Протоколы ошибок. Некоторые программы при сбоях создают 
протоколы ошибок. Если система, предназначенная для тестирова- 
ния, или какое-либо сосуществующее приложение дает сбой до, во 
время или после того, как тестируемая система продемонстрирова- 
ла ошибочное поведение, нужно рассмотреть вопрос о включении 
файлов с протоколами в отчет об ошибке. 


Большинство описанных элементов — файлы. Удобные инструменты 
управления дефектами, предлагаемые на рынке, позволяют тестировщи- 
ку присоединять один и более файлов к отчету об ошибке. Если ваши 
средства управления дефектами не позволяют это делать, то группа тести- 
рования может создать структуру каталогов где-то на сетевом диске обще- 
го доступа, в котором тестировщики сохраняют такие файлы, а програм- 
мисты их просматривают. 

Другим важным видом внешней информации являются измерения де- 
фектов. Как упоминалось в главе 13, процесс выполнения тестов должен 
поддерживать сбор основных измерений для управления тестированием 
и проектом в целом. Процесс подготовки отчетов об ошибках обязан пре- 
доставлять всю важную информацию, необходимую для измерений. Нуж- 
но четко следовать процессу, поскольку измерения, для которых сущест- 
венны даты, должны иметь четкую информацию о датах. Тестировщики 
должны тщательно определять категории ошибок, например затронутые 
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подсистемы, чтобы измерения, касающиеся анализа ошибок по категори- 
ям, имели смысл. 

Последний вид полезной внешней информации — это информация об 
обходных путях. Некаждая ошибка может и должна быть исправлена. Для 
таких ошибок полезно знать обходные пути. Тестировщики могут доку- 
ментировать обходные пути для пользователей. Тестировщики могут 
проверить, что обходные пути переданы службам технической поддерж- 
ки или сетевой поддержки пользователей. В одном из проектов в конце 
системного тестированияу нас был период передачи дел, в ходе которого 
два тестировщика совместно с двумя сотрудниками группы технической 
поддержки просмотрели все известные неисправленные ошибки и убеди- 
лись в том, что двое последних разобрались в каждой ошибке и знают все 
возможные обходные пути. 

Потребность в действенной передаче информации означает, что при- 
менимы обычные правила написания технической документации. Текст 
должен быть ясным и обязан вскрывать суть проблемы. Он должен соот- 
ветствовать аудитории и излагаться понятными ей словами. Если отчеты 
об ошибках используют жаргонные выражения и сокращения, это долж- 
ны быть хорошо известные проектные термины. 

Одним из признаков неэффективной передачи информации является 
то, что я обычно называю отфутболиванием (ріпе-ропе) отчетов об ошибках. 
Это такая игра, в которой участвуют тестировщик и программист: проис- 
ходит непродуктивное перебрасывание друг другу отчета об ошибке. Вот 
некоторые типичные причины отфутболивания отчетов об ошибках. 


= Программист утверждает, что ошибка неверно отнесена к его ком- 
поненту или фрагменту кода. 


и Программист отвечает, что ошибка является невоспроизводимой 
или это верное поведение программы. 


и Возникли личные трения между программистом и тестировщиком, 
поэтому программист не может допустить, чтобы тестировщик при 
помощи отчета об ошибке набирал очки против него. 


Проблемы, которые являются невоспроизводимыми или рассматри- 
ваются как работа программы в соответствии с проектом, могут быть 
решены посредством тщательной подготовки отчетов об ошибках, в част- 
ности, за счет документирования шагов воспроизведения ошибки, срав- 
нения ожидаемого результата с фактическим и установления факта, что 
проблема воспроизводится не всегда. 

Неприятный вопрос - назначение ответственных за исправление 
ошибки. Необходимо делать различие между тем, где визуально зафикси- 
рованы симптомы ошибки, где ошибка находится в системе и где ее луч- 
ше исправить. В одном из проектов мы обнаружили ошибку, вызывавшую 
потерю данных в файлах, которые сохранялись приложениями в систе- 
ме, предназначенной для тестирования. Истинной причиной была несо- 
вместимость аппаратных средств, неправильным было соединение жест- 
кого диска (шина ІДЕ) с тестируемой системой. Проблема была 
исправлена после того, как было внесено изменение в базовую систему 
ввода- вывода компьютера, которое оказало влияние на время выполне- 
ния операционной системой операций чтения и записи на жесткий диск. 
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Где же была эта ошибка? В приложении, теряющем данные? В способе пе- 
редачи информации с жесткого диска в систему? Или в способе, при по- 
мощи которого система взаимодействовала с диском? Или в коде чтения 
и записи ВІОЅ? 

С точки зрения качества мы, по всей вероятности, можем не думать 
о том, где находилась ошибка или как она исправлена, поскольку неприем- 
лемое поведение теперь отсутствует. Однако с точки зрения проекта эти 
вопросы иногда приобретают огромное политическое значение. Руково- 
дство хочет определить последовательность действий, которая позволит 
точно определять ответственных за исправление ошибки, а выбор подхо- 
дящего средства для подготовки отчетов об ошибках способствует под- 
держке этой последовательности действий. Только менеджер разработки, 
а не группа тестирования, должен отвечать за назначение ответственных 
за исправление тех или иных проблем системы. 


Включение одного симптома в каждый отчет 
и подготовка одного отчета на каждый симптом 


Отчеты об ошибках описывают симптомы — наблюдаемое аномальное по- 
ведение, в то время как исправление ошибок — это работа с дефектами 
в системе. Бывает так, что непохожие отчеты об ошибках описывают один 
и тот же дефект в системе. Однако опыт показывает, что это нетипично. 
Дублирование отчетов об ошибках обычно происходит, когда два тести- 
ровщика сообщают об одном и том же неверном поведении в двух различ- 
ных отчетах об ошибках. Дублирование отчетов в этом случае означает 
дублирование работ тестировщиками, программистами и менеджерами. 

Обратное также может иметь место. Тестировщики иногда соединяют 
два-три симптома, которые проявляются вместе в сценарии использова- 
ния или в функциональной области системы. Я часто наблюдал, что в 
этом случае исправлялись не все документированные проблемы. Далее 
тестировщики вынуждены либо создавать один или несколько новых от- 
четов об ошибках, описывающих оставшиеся проблемы, либо повторно 
открывать существующий отчет об ошибке. При этом расходуется время 
программиста и тестировщика, а система управления дефектами неэф- 
фективно воздействует на процесс. В итоге работа по подготовке отчетов 
об ошибках неверно отражает реальную картину, поэтому получаемые из- 
мерения являются искаженными. 

Как и в рамках всего процесса, здесь требуется здравый смысл. Я луч- 
ше подготовлю два отчета об ошибках, чем не напишу их вовсе. Поэтому 
я говорю тестировщикам, чтобы они не тратили больше пяти минут на 
поиск в системе управления дефектами существующего отчета об ошиб- 
ке. Кроме того, я предпочитаю, чтобы тестировщики обменивались свои- 
ми отчетами об ошибках со всей группой тестирования по электронной 
почте либо для рецензирования, либо просто для информации. Я заме- 
тил, что такой способ работы снижает количество дублированных отче- 
тов примерно до 5-10%, это вполне приемлемая цифра. 

Мне не нравится, если тестировщики тратят слишком много времени 
на выяснение того, является ли проблема последствием одной или не- 
скольких ошибок. По моему мнению, процесс рецензирования обычно 
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позволяет выявить достаточное количество таких видов отчетов об 
ошибках, поэтому я не слишком беспокоюсь об этом. 


Установка четкой границы между тестированием и отладкой 


Как отмечал Борис Бейзер, вначале место тестирования определялось 
как дополнение к отладке. По мере становления тестирование стало рас- 
сматриваться как отдельная совокупность задач, направленных на лока- 
лизацию ошибок и управление рисками качества!. В компаниях с незави- 
симыми группами тестирования тестировщики направляют свои усилия 
на тестирование, а программисты выполняют задачи отладки. 

В главе 16 этот вопрос рассматривается более подробно, здесь же ко- 
ротко исследуем процесс, связанный с обнаружением симптома, исправ- 
лением соответствующего дефекта и проверкой исправления (см. 
рис. 14.1). Первые три этапа процесса — действия тестирования, которые 
выполняются группой тестирования и проводятся параллельно с процес- 
сом создания отчета об ошибке. Следующие три этапа — это действия от- 
ладки, которые выполняются группой разработки и являются частью 
устранения проблемы, описанной в отчете об ошибке группой тестирова- 
ния. Заключительный этап — это проверочное и регрессионное тестиро- 
вание, которое снова является действием тестирования. Следовательно, 
это совместный процесс, состоящий из семи этапов, направленный на по- 
вышение качества тестируемой системы за счет циклических корректи- 
рующих действий, управляемых отчетами об ошибках. Это совместный 
процесс, но каждая отдельная задача выполняется либо группой тестиро- 
вания, либо группой разработки. 

Удобный процесс подготовки отчетов об ошибках поддерживает та- 
кое распределение обязанностей. Как отмечалось ранее, хороший отчет 
об ошибке предоставляет программисту всю информацию, необходимую 
для воспроизведения проблемы и поиска дефекта. Подготовка отчетов об 
ошибке и процессы управления дефектами — это единственные инстру- 
менты, необходимые для обмена информацией между двумя группами. 
Это показывают события передачи информации на рис. 14.1. Процесс 
подготовки отчетов об ошибках должен избавлять программиста от необ- 
ходимости задавать вопросы тестировщику о том, в чем состоит смысл 
его отчета об ошибке. Процесс должен также избавлять тестировщика от 
необходимости тратить время на повторные усилия по воспроизведению 
ошибки для программиста. 

Я не одобряю участия тестировщиков в отладке. Объясню, почему это 
столь важно для меня, когда я выполняю обязанности тест-менеджера. 


1. Есть много работы по тестированию, которую должны выполнить 
тестировщики. Я обязан отчитываться за эту работу. Когда тести- 
ровщики помогают исправлять проблемы программистам, они не 
заняты выполнением ключевых процессов тестирования. 


2. Я не могу управлять тестированием, когда тестировщики по своему 
усмотрению отдают свои силы и свое время группе разработки. 


1 см. книгу Бориса Бейзера “ЗоДшате Теѕйпр Тесйтдиг5”. 
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3, Какие факторы оказывают влияние на отказ? 


Часть ІМ. Совершенствование 


4. Какова основная причина отказа? 


не внося новых проблем? 
6. Подверглось ли исправление надлежащей отладке? 


Процесс тестирования 


1. Можно ли воспроизвести отказ? 7. Устранена ли проблема? Успешно ли проходит 
2. Что означает отказ: ошибку теста система тот тест, который ранее приводил к отказу? 
или ошибку системы? Работает ли по-прежнему верно остальная часть 


системы? 


Рис. 141. Процесс поиска, отладки и проверки исправления ошибки 


Часть управления состоит в том, чтобы распределить людские 
ресурсы согласно корпоративным целям. Я не могу допустить пере- 
распределения ресурсов по желанию тестировщика, который, чест- 
ноговоря, может не видеть всей глубины расстановки приоритетов. 


3. Помощь в отладке, которую оказывают тестировщики, редко явля- 
ется разумным использованием ресурсов. Даже при условии, что 
тестировщик — опытный программист, причиной того, что он за- 
нимается тестированием, а не программированием, является то, 
что он более ценен для компании в роли тестировщика. 


4. Это укрепляет самомнение и выглядит как работа в команде, но не 
способствует развитию карьеры. Я с удовольствием организую ра- 
боту тестировщика так, чтобы поддержать выбор карьеры програм: 
миста, добавив задачи создания инструментов и автоматизации тес- 
тирования в его рабочую нагрузку. Такие действия больше 
подходят для освоения программирования, чем участие в отладке, 
что выглядит больше как путешествие в программирование, а не 
потенциальная информация в резюме. 


5. Эти действия обычно указывают на слабые отчеты об ошибках, 
подготовленные тестировщиком. Если программист не может 
понять, что неверно работает, при помощи отчета об ошибке и 
вынужден спрашивать тестировщика, то решением является бо- 
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лее жесткий процесс подготовки отчетов об ошибках, а не уча- 
стие тестировщика в отладке. 


В некоторых случаях тестировщики обязаны принимать участие в от- 
ладке, особенно если для воспроизведения проблемы необходимы уни- 
кальные конфигурации тестов или инструменты тестирования. Это, без- 
условно, исключение из правил, и удобный процесс подготовки отчетов 
об ошибках сводит к минимуму эту необходимость. 


Решение проблем 


Подготовка отчетов об ошибках ставит группу тестирования перед рядом 
проблем даже в том случае, когда процесс написания отчетов является со- 
вершенным. Эти проблемы носят как технический (трудно готовить от- 
четы о неизвестном), так и политический (необходимо управлять меж- 
личностными и групповыми отношениями, частью которых является 
критика работы других) характер. 


Разделение ошибок, свойств и ответов “ну, и что?” 


Противоречивость или полное отсутствие спецификаций требований 
или архитектуры может усложнить процесс подготовки отчетов об ошиб- 
ках. Когда программисты отвечают на отчеты об ошибках комментария- 
ми типа “как раз так система и должна работать”, у тестировщиков отсут- 
ствует ясный способ для того, чтобы опровергнуть это утверждение. 
Обычно я пытаюсь разрешить противоречие, обсуждая его с различными 
заинтересованными сторонами, и не допускаю вовлечения собственного 
мнения в проблему. Менеджеры технической или сетевой поддержки 
пользователей, группы продаж и маркетинга, бизнес- аналитики, менед- 
жер разработки и другие руководители проекта, вероятно, имеют собст- 
венные мнения по поводу того, как должен вести себя продукт. Кроме 
того, группауправления изменениями или комиссия по разбору дефектов 
(см. главу 16) должна уметь отделять ошибки от недокументированных 
свойств. 

Один из возможных ответов программистов и менеджеров на отчет об 
ошибке: “ну, и что?” или “ни один настоящий пользователь никогда этого 
не сделает” и т.п. Это может быть признаком того, что менеджер или про- 
граммист, делающий такие замечания, не беспокоится о качестве систе- 
мы, запутался в требованиях (зафиксированных или нет) или столкнулся 
с какой-то похожей проблемой. Либо это признак того, что тестировщик, 
написавший отчет об ошибке, не смог донести суть проблемы до другой 
стороны. 

Тестировщики должны искать способ увязать любую обнаруженную 
ошибку с реальной жизнью, особенно при выполнении тестов, которые, 
возможно, не имеют отношения к реальным сценариям действий пользо- 
вателя. Тестировщики, которые этого не делают, не должны удивляться, 
услышав “ну, и что?” Эффективная передача информации о результатах 
тестирования является прямой обязанностью тестировщиков, поскольку 
именно мы предоставляем эту услугу. На нас, тестировщиков, возложена 


418 


Часть ІУ. Совершенствование 


обязанность доказывать, что мы нашли ошибку. Группы разработки 
и управления проектом не должны верить нам на слово, что некоторая 
невразумительная проблема указывает на глубокую ошибку в системе. 

Программисты являются основными внутренними потребителями на- 
ших отчетов об ошибках, поэтому они судят о качестве содержания отче- 
тов. Если их устраивает сообщение тестировщика: “Эй, проверь, что за 
непонятное поведение я наблюдал”, отлично. Редко, но я встречался с та- 
ким типом любопытных программистов в проектах с сильным управлени- 
ем, когда качество рассматривалось как столь же важный компонент про- 
екта, как сроки, бюджет и свойства. Тем не менее, тестировщики обязаны 
понимать информационные потребности программистов, когда они от- 
правляют программистам отчеты об ошибках. 

Менеджеры проектов — это еще одна ключевая группа внутренних по- 
требителей отчетов об ошибках. Они обычно хотят знать, почему они 
должны вкладывать ресурсы проекта — загрузку программиста и плани- 
руемое время в проекте - в исправление ошибок. Мои наиболее неотра- 
зимые аргументы описывают, какой ущерб могут причинить ошибки за- 
казчикам или пользователям, что в итоге выльется в (потенциально 
большое) количество звонков в группу технической поддержки и в другие 
менее ощутимые затраты на (низкое) качество. Когда программисты ис- 
пытывают сильное давление со стороны сроков и/или бюджета, по моим 
наблюдениям, они часто демонстрируют похожие подходы к разбору 
ошибок. В любом из проектов, где ограничения сроков и бюджета лими- 
тируют число проблем качества, которые могут быть разрешены, поиск 
влияния ошибок на пользователя является наилучшим подходом при под- 
готовке отчетов об ошибках. 

Вот почему в своем процессе подготовки отчетов об ошибках я делаю 
ударение наувязывании отказа с проблемами заказчика, особенно в крат- 
ком описании. Краткое описание является ключевым, поскольку это не- 
редко единственная часть отчета об ошибке, которую прочитывают 
в ходе совещания группы управления изменениями или комиссии по раз- 
бору ошибок, так как ошибок может быть очень много. 

Я также рекомендую, чтобы тестировщики четко описывали в разде- 
лах “Шаги воспроизведения” и “Локализация” поведение, которое они 
ожидали увидеть, поведение, которое они видели фактически, и значе- 
ние (с точки зрения пользователя) различия между двумя вариантами по- 
ведения. В нашем примере подразумевалось, что повреждение данных 
является нежелательным поведением, однако для многих ошибок поведе- 
ние может казаться разумным, но быть ошибочным в определенном смыс- 
ле. Тестировщики должны отразить это в своих отчетах об ошибках. 

Я стимулирую тестировщиков занимать активную позицию в отделе- 
нии друг от друга ошибок, свойств и “ну и что?”, а не просто набивать базу 
данных дефектов отчетами об ошибках, игнорируя обвинения програм: 
мистов и других сотрудников проектной группы о наличии в сигнале че- 
ресчур большого шума. Вновь повторю, поскольку мы предоставляем 
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тот раздел появился в результате онлайновой беседы с Бреттом Петикордом, Джейм- 


сом Бачем, Семом Канером, Россом Коллардом, Кэти Айберли и Аланом Иоргенсеном. 
Я благодарю участников за их вклад в обсуждение, хотя здесь отражена только моя точка 
зрения. 
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группе проекта информационные услуги, мы несем ответственность за 
эффективную передачу этой информации. Если они рассматривают нашу 
информацию как шум, что-то серьезно нарушено. Мне рассказывали кол- 
леги, что в ситуациях, когда тестировщики игнорировали эту проблему, 
случалось так, что тестировщики должны были получить разрешение от 
сотрудников группы разработки или других групп проекта на открытие 
отчета об ошибке. 

Пожалуйста, примите к сведению, что я не выступаю в защиту игнори- 
рования проблем на основании того, что кто-то считает их несуществен- 
ными или мелкими. Тестировщики, как и программисты, часто не облада- 
ют достаточной информацией для принятия решений о том, что точно 
означает качество для тестируемой системы. Если мы, тестировщики, ре- 
шим игнорировать определенную проблему, будучи уверенными в том, 
что ни для кого из пользователей это не будет проблемой, то может слу- 
читься так, что позже к нам придут сотрудники групп продаж, маркетинга 
или аналитики и спросят, почему столь очевидные ошибки не были най- 
дены при тестировании. Однако, как отмечалось в главе 13, есть время, 
чтобы сконцентрировать усилия на опасных областях, и есть время на на- 
ведение лоска в продукте. 


Обработка случайно исправленных ошибок 
и невоспроизводимых симптомов 


Однажды я работал в проекте, где менеджер разработки готовил новые 
версии ежедневно и даже каждый час, если обнаруживались ошибки, тре- 
бующие срочного исправления. Мы решили не принимать столь часто 
версии в тестовую лабораторию, поскольку это нарушало бы процесс вы- 
полнения тестов требованием постоянно заниматься проверочным тес- 
тированием. (Представьте, что вы ведете машину и смотрите только в 
зеркало заднего вида.) На каждом совещании по разбору ошибок менед- 
жер разработки в ответ на любую серьезную ошибку независимо от того, 
уже занималась исправлением ошибок его группа или нет, говорил: “Про- 
верьте нашу последнюю версию. Я думаю, что мы устранили эту пробле- 
му”. В конце концов я не выдержал и сказал ему: “Знаешь ли, ты, верно, ду- 
маешь, что исправил все эти ошибки случайно, но мой опыт показывает, 
что значительно меньше ошибок устраняется случайно, чем это хотелось 
бы менеджерам разработки. Пока ты не потратишь немного времени на 
то, чтобы воспроизвести проблему и исправить ошибку, я не собираюсь 
просить свою группу тратить время на перетестирование ошибок”. 

Мой ответ был довольно грубым, но ясчитаю его верным в отношений 
моих дальнейших действий. Ошибки обычно не устраняются случайно. 
Честно говоря, менеджер разработки в этой истории использовал запрос 
на перетестирование каждой ошибки в каждой новой версии, рассчиты- 
вая на то, что каким-то волшебным образом многие из них исчезнут и уда- 
стся скрыть тот факт, что качество системы ужасно низкое. Он надеялся 
использовать это средство в качестве механизма ослабления натиска де- 
фектов, о которых сообщала группа тестирования. 

Тратить время тестировщика на перетестирование ошибок, на ис- 
правление которых никто не потратил ни миллисекунды времени, — это 
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неэффективное использование времени группы тестирования. В таких 
обстоятельствах я бы предпочел обсудить с проектной группой процесс, 
в соответствии с которым до того, как отчет об ошибке будет возвращен 
группе тестирования для проверочного тестирования, программист дол- 
жен проверить систему и выяснить, осталась ли проблема. 

Другим препятствием, сильно осложняющим нашу жизнь, является 
то, что некоторые ошибки не воспроизводят один и тот же симптом 
вновь и вновь по команде, как проверенный штамп. Например, утечки па- 
мяти зависят от особых условий, возникающих иногда в течение длитель- 
ного периода времени до того, как система потерпит крах или работа с 
приложением будет блокирована. Однажды я работал в проекте, в кото- 
ром нерегулярно нарушались модемные соединения, но нам не удалось 
заставить проблему возникать, когда необходимо. В конечном счете, про- 
граммисты вынуждены были добавить специальные средства в програм- 
му, чтобы отследить проблему. 

Некоторые смешивают появляющиеся время от времени проблемы с не 
существенными проблемами. Во многих случаях периодические пробле- 
мы являются серьезными ошибками. Крах систем, нарушение модем- 
ных или сетевых соединений или внезапный отказ части системы как 
реакция на входные данные может полностью нарушить работу пользо- 
вателя и даже повредить его данные. Свойства, работающие время от 
времени, — это свойства, применения которых будет избегать пользо- 
ватель. 

Поэтому я всегда скептически отношусь к заявлению, что серьезная пе- 
риодически возникающая ошибка “просто исчезла”, раз ни программисты, 
ни тестировщики не могут воспроизвести ее. Обычно я держу такие ошиб- 
ки открытыми на протяжении нескольких версий (две-три недели), чтобы 
убедиться, что мы не встречаемся с ними вновь. (В некоторых компаниях 
есть специальное состояние “наблюдение” или “мониторинг”, в котором 
хранятся такие ошибки.) Я спрашиваю программистов, чем может помочь 
группа тестирования в ходе наблюдения такой проблемы. Например, пере- 
загрузка зависшей системы обычно разрушает данные состояния, которые 
могли бы помочь программисту отследить ошибку. Вероятно, программи- 
сты попросят покопаться в системе и зафиксировать эту информацию при 
помощи сети. И я должен удостовериться в том, что запись ведется всякий 
раз, когда ошибка действительно проявляется. Ощущение ненадежности 
системы, которую может вызвать такая ошибка, является исключительно 
важным для разумной расстановки приоритетов при исправлении оши- 
бок, и это означает, что я должен быть способен отчитаться о частоте воз- 


‘никновения ошибки. 


Удаление шума из сигнала 


Система управления ошибками является полезным, но не единственным 
способом коммуникации, и она не должна применяться для обсуждения 
всех проблем. Поскольку мы пишем отчеты об ошибках для обсуждения 
проблемы в тестируемой системе, для принятия решения о ее приорите- 
те и устранении, мы должны быть уверены в том, что используем канал, 
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который создан при помощи процессов подготовки отчетов об ошибках 
и управления дефектами исключительно для этой цели. 

Сложности возникают, когда этот инструмент начинают использовать 
для эскалации проблем руководству. Я стараюсь избегать пересылки в сис 
тему управления дефектами отчетов об ошибках, которые сообщают о сбоях 
в процессе разработки системы, а не в системе, предназначенной для тести- 
рования. Например, если инженер сборок не передал в понедельник в 9 ча- 
сов утра сборку, я не буду писать отчет об ошибке с названием “Сборка не 
передана в срок”. Я пойду к инженеру сборок и объясню ему значение 
своевременного получения версий. Если проблема повторяется, я пере- 
даю ее на уровень руководства инженера сборок. Конечно, если сборка 
передана в срок, но отказывается работать, вероятно, я напишу отчет об 
ошибке под заголовком “Сборка 781 не инсталлируется”. 

Сложности возникают также, когда некоторые делают личные помет- 
ки в базе данных управления дефектами. Я работал в проекте, где один из 
лучших программистов, наиболее отзывчивый партнер со стороны раз- 
работки, о котором только мечтают тестировщики, имел привычку де- 
лать персональные пометки в базе дефектов. Поскольку он был единст- 
венным, это не вызывало больших проблем. Однако если каждый 
программист сделает для себя одну пометку в день, мы получим 25 отче- 
тов об ошибках в системе, которые не будут иметь никакого отношения к 
ошибкам. 

Наконец, проблема шума существует, когда тестировщики сообщают 
об ошибках, которые таковыми не являются. В главе 13 отмечалось, как 
важно делать различия между ошибками в системе, предназначенной для 
тестирования, ошибками в системе тестов и обычным непониманием 
того, как должна работать система. В процессе подготовки отчетов о де- 
фектах воспроизведение проблемы и локализация причины сбоя, атакже 
итоговый перекрестный просмотр отчета помогают понять, в чем состо- 
ит проблема. 

В любом из этих случаев добавляется шум в ценный информационный 
канал. Шум может ввести в заблуждение тестировщиков и программи- 
стов, испортить процессы подготовки отчетов об ошибках, подготовки 
отчетов о ходе работ по тестированию (см. главу 15) иуправления измене- 
ниями (см. главу 16), а также исказить измерения проекта, с какой бы мо- 
делью устранения дефектов вы ни работали. 


Создание доверительных отношений с программистами 


В моей группе работал тестировщик, который сказал мне, что ему нравит- 
ся тестирование, потому что он имеет шанс поймать программистов на 
ошибке. Он сохранял информацию о том, в чьих компонентах он обнару- 
жил проблемы, и не успокаивался до тех пор, пока не находил ошибку 
в коде каждого программиста. Такой тип отношений, при котором про- 
граммист пытается скрыть ошибки от тестировщика, может породить 
большие проблемы с отчетами об ошибках. Если программисты воспри- 
нимают тестирование, как игру в салочки, и рассматривают отчет об 
ошибке в их компоненте, как будто им теперь нужно “водить”, то, без со- 
мнения, возникнет проблема отфутболивания отчетов. 
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Другая ловушка возникает тогда, когда тестировщики или тест-менед- 
жеры начинают отслеживать работу отдельных программистов, ожидая 
исправления ошибки. Такой подход может породить целую совокупность 
проблем. Во-первых, если программисты не готовят отчеты для тестиров- 
щиков, тестировщики не обладают достаточной информацией для того, 
чтобы понять, какие еще задачи нужно поручить программистам. Нару- 
шение приоритетов не способствует расположению программистов и ме- 
неджеров к вам. Во-вторых, если тестировщики не имеют авторитета у 
программистов, они воспринимаются только как раздражители, не при- 
носящие никакого полезного результата. Тестировщики могут иногда 
привлекать программистов к работе над ошибками с помощью взяток 
(обед) или интеллектуального вызова (написанием увлекательного отче- 
та об ошибке), но желание получить свободу вуправлении другой группой 
обычно не срабатывает. 

Проблемы возникают и втех случаях, когда тестировщики используют 
данные отчетов об ошибках для составления графиков или отчетов, кото- 
рые представляют отдельных людей в неприятном свете. Например, мно- 
гие инструменты управления дефектами содержат поле “Примерная дата 
исправления”, которую программисты заполняют, исходя из своих воз- 
можностей. Подготовка отчета, который для каждого программиста по- 
казывает, какие ошибки еще не исправлены и по каким сроки уже про- 
шли, будет унизительной. Аналогично, подготовка отчета, в котором 
ошибки отсортированы и собраны по компонентам или подсистемам и 
содержат указание ответственного, т.е. указывают, кто внес ошибку в код, 
является вредным для обвиняемых программистов. 

Еще одна проблема — доверие. Если мы занесем в систему слишком мно- 
го отчетов об ошибках, которые не являются проблемами, или совершим 
слишком много ошибок при интерпретации результатов тестирования, 
рано или поздно создастся впечатление, что тестировщики предоставля- 
ют информацию, которой не стоит доверять. Мой опыт показывает, что 
для нанесения ущерба доверию группе тестирования не надо слишком мно- 
го шума со стороны группы. 

Тема корректной интерпретации результатов тестирования подробно 
рассматривалась в главе 13. Структурированное тестирование является не 
только основой процесса подготовки отчетов об ошибках, но и основой 
для доверительных отношений между программистами и тестировщика- 
ми. По-моему мнению, при подготовке отчетов об ошибках помогут сле- 
дующие пять советов. 


1. Ориентируйтесь на оказание услуг всему проекту. Какие информа- 
ционные услуги вы можете оказать как тестировщик, чтобы содей- 
ствовать успеху проекта? 


2. Сохраняйте спокойствие в ходе обсуждения отчетов об ошибках 
с программистами, менеджерами и другими сотрудниками проект- 
ной группы. Защита качества — это хорошо, но гнев, неумение дер- 
жать себя в руках неуместны. 


3.. Открыто обсуждайте отчеты об ошибках с пониманием того, что 
есть вероятность и вашей ошибки. Защищайте разумные ожидания 
заказчиков. 


Глава 14. Когда качество не оправдывает ожиданий 423 


4. Передавайте только отчеты об ошибках качества системы, будьте 
открыты для предложений по повышению качества отчетов об 
ошибках. Необходимо помнить, что проектная группа, выступая в 
роли заказчика ваших информационных продуктов, принимает ре- 
шение в том, что означает качество. 


5. Проявляйте гибкость в подготовке и передаче отчетов об ошибках. 
Если программисту требуется определенный файл или снимок эк- 
рана, прикрепленный к отчету об ошибке (если система управле- 
ния дефектами поддерживает прикрепление файлов), необходимо 
проявлять стремление к сотрудничеству. 


Как только возникнет ощущение, что мы серьезно нацелены на пере- 
дачу понятных отчетов об ошибках способом, удобным для всех участни- 
ков проекта, информация об этом быстро распространится по компании. 


Выбор инструмента управления дефектами 


Хороший инструмент управления дефектами должен способствовать сбо- 
руи управлению информацией, о которой говорилось выше. Но нам тре- 
буется несколько больше. Если сбор информации и управление — это все, 
что нам нужно, мы можем в качестве инструмента управления дефектами 
использовать обычную базу данных. Однако основная ценность удобного 
инструмента управления дефектами состоит в его способности собирать 
информацию и управлять ею в ходе всего жизненного цикла каждого от- 
чета об ошибке, начиная с первого обнаружения и заканчивая ее оконча- 
тельным устранением или отсрочкой. 

Нарис. 14.2 показан один из возможных вариантов жизненного цикла 
дефекта. Отчеты об ошибках проходят через последовательность состоя- 
ний (жизненного цикла) до окончательного устранения в виде либо от- 
клонения отчета, либо проверенного закрытия проблемы, либо отсроч- 
ки симптома (и всех связанных отчетов об ошибках) как несущественного 
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Рис. 14.2. | Жизненный цикл ошибки 
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для исправления в данной версии. Для каждого состояния, не являющего- 
ся заключительным, менеджер или группа управления изменениями 
(см. главу 16) определяет ответственного, который должен переместить 
ошибку в очередное состояние. Удобная система управления дефектами 
позволяет реализовать и автоматизировать такой жизненный цикл, хотя 
необходима поддержка процесса управления дефектами со стороны груп- 
пы проекта и руководства. Как правило, по мере того как участники про- 
цесса изменяют состояние отчета об ошибке, они протоколируют изме- 
нения, состояние или вводят запись истории в базу данных отчетов об 
ошибках. 

Степень, в которой сценарий работы систем управления дефектами 
может быть приспособлен к жизненному циклу ошибок в вашем проекте, 
является ключевой метрикой качества инструмента управления дефекта- 
ми. (Если руководство не обладает достаточным опытом в определении 
жизненного цикла, следует начать со сценария работы, заложенного в ин- 
струмент по умолчанию, а затем постепенно настроить его на потребно- 
сти компании.) Состояния в жизненном цикле отчетов об ошибках долж- 
ны представлять ключевых участников процессов обнаружения, 
исправления и проверки устранения дефектов. Переходы между состоя- 
ниями показывают передачу управления между этими ключевыми участ- 
никами. 

Заметим, что поддержка жизненного цикла в системе управления де- 
фектами может и, вероятно, должна быть тесно интегрирована с управ- 
лением версиями. Удобная система управления дефектами позволяет 
группе разработки при подготовке тестовой версии делать пометки “го- 
тов ктестированию” в отчетах об ошибках и запросах на усовершенство- 
вание, связанных с изменениями в версии. По получении версии группа 
тестирования может получить отчет с перечнем всех элементов, находя- 
щихся в состоянии “готов к тестированию”. Часто системы управления 
дефектами могут взаимодействовать с инструментами управления кон- 
фигурацией, что позволяет автоматизировать большую часть этого про- 
цесса . 


Внедрение усовершенствований 


Подготовка отчетов об ошибках как процесс и как действие в любом 
проекте редко идет идеально. Как поставить процесс подготовки отче- 
тов об ошибках под контроль, зависит в значительной мере оттого, в ка- 
ком состоянии текущий процесс. Однако хочу внести несколько предло- 
жений. 


1. Сначала устраните неверное отношение тестировщиков к отчетам. 
Лучший в мире процесс ничего не сможет сделать, если тестиров- 


Я подробно рассматриваю тему инструментов управления дефектами в книге “ Мапаріпр 
Ше Тезійпр Ргосезз, Зесопа Е@ от”. Могу также порекомендовать исследование процесса выбора 
инструментов тестирования в книге "5о/їшате Те Аиіотайот Марка Фьюстера и Дороти 
Грэм. 
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щики и программисты используют процесс подготовки отчетов об 
ошибках в качестве оружия друг против друга. 


Отчет об ошибке — это наиболее осязаемая часть информацион- 
ных продуктов, подготавливаемых тестировщиками. Любая работа 
по усовершенствованию процесса, нацеленная на получение более 
качественного продукта, начинается с переговоров с заказчиками. 
Кто будет читать ваши отчеты об ошибках? Что им нравится и что 
не нравится в текущем процессе? Какие направления по улучше- 
нию отчетов об ошибках им кажутся предпочтительными? Начни- 
те задавать эти вопросы. И уже это станет мощным сигналом для ра- 
бочей группы проекта, особенно когда они увидят работу над их 
идеями. 
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3. Если у вас нет инструмента управления дефектами, приобретите 
его. Такие инструменты не обязательно дороги, и даже существуют 
бесплатные продукты!. При необходимости можно использовать 
таблицы, но текстовые файлы, документы обработки текстов или 
совокупность электронных сообщений здесь не помогут. Посколь- 
ку частью подготовки отчетов об ошибках является сбор измере- 
ний, мы не можем использовать инструменты, которые не поддер- 
живают общий анализ данных об ошибках. 


4. Изучите последовательность действий, которая имеет место при 
обнаружении, исправлении и проверкеустранения ошибок, и срав- 
ните ее с тем, что позволяет сделать имеющийся у вас инструмент 
управления дефектами. Каковы ключевые участники последова- 
тельности действий и как происходят передачи ошибок? Можно ли 
улучшить жизненный цикл, заложенный в инструмент, чтобы бо- 
лее качественно собирать информацию о процессах, соглашениях, 
передачах и ключевых участниках? 


5. Если у вас уже есть инструмент, нужно попытаться приспособить 
его к поддержке удобного процесса подготовки отчетов об ошиб- 
ках, прежде чем принимать решение о замене инструмента. Изме- 
нение системы управления дефектами — это важное решение, осо- 
бенно если вы находитесь в середине проекта. Технические 
проблемы, связанные с миграцией данных из одного инструмента в 
другой, далеко не тривиальны. Мы с одним из моих коллег как-то 
провели несколько недель за этим занятием. Имеются также поли- 
тические проблемы. Системы управления дефектами обычно ис- 
пользуются и другими группами, в том числе группой сборки вер- 
сий, группой разработки, группой технической поддержки. Кроме 
того, менеджеры этих групп часто делают собственные инструмен- 
тальные панели, использующие данные управления дефектами. 
В определенное время замена систем управления дефектами может 
иметь смысл, однако мне удавалось справляться даже с такой систе- 
мой, которую я считаю одной из худших систем управления дефек- 
тами на рынке. 


6. Применяйте удобный процесс подготовки отчетов о дефектах, но 
проявляйте гибкость и чувство приоритетов. В моих группах было 
только одно нерушимое правило в процессе — каждый отчет об 
ошибке должен пройти перекрестное рецензирование. 


7. Опробуйте проведение перекрестного рецензирования, прежде 
чем отказаться от него как от препятствия на пути к эффективному 
тестированию. Плохие отчеты об ошибках могут привести к беспо- 
лезному расходу времени. Перекрестные рецензии можно упро- 
стить до прочтения непосредственно на экране тестировщиком от- 


Например, базу данных М1сгозой Ассезз, описанную в моей книге "Мапаріпр іће Теѕйпр 
Рүосеѕѕ, $есопа Енот”, можно бесплатно скачать с меб-сайта ууу.гехЫасксопѕиііпӯ.сот. 
(Даже если вы не захотите использовать мою базу данных, возможно, будет полезно про- 
смотреть набор полей, которые применяются при отслеживании ошибок и управлении 
ими.) Стив Сплейн в книге “Тезётр Иер 5еситіїу" приводит целый список инструментов управ- 
ления дефектами. Можно также скачать ВиртШа с сайта уму. тоПа.огр. 
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чета об ошибке другого тестировщика перед тем, как отправить его 
в систему управления дефектами. 


Рассмотрите введение метрик для измерения качества отчетов об 
ошибках. Например, каков процент вновь открытых отчетов об 
ошибках? Другими словами, как много отчетов возвращается с от- 
метками “исправлено”, “работает в соответствии с проектом” или 
“невоспроизводимо”, тогда как указанные ошибки не исправлены, 
на самом деле ошибки имеются в проекте или легко воспроизводят- 
ся? Другой метрикой может быть среднее время, в течение которо- 
го отчеты об ошибках остаются открытыми. Удобный процесс под- 
готовки отчетов об ошибках должен способствовать снижению 
этих показателей. 


Какие бы изменения вы ни внедряли, важно сохранять терпение и 
проявлять настойчивость. Люди вырабатывают привычки в работе, осо- 
бенно вотношении задач, которые приходится выполнять вновь и вновь. 
Нужно иметь это в виду при работе над улучшением процесса подготовки 
отчетов об ошибках. 


ГЛАВА 15 


Четвертый элемент: 
подготовка отчетов 
о результатах тестирования 


авным-давно философы верили, что мир создан из четырех элемен- 

тов: земли, ветра, огня и воды. Современная химия учит нас, что су- 
ществует более сотни элементов. Тем не менее, проекты, в которых я ра- 
ботал, обычно состояли из четырех основных элементов. 


ш Свойства. Создаем ли мы необходимое множество функций, кото- 
рые решают проблемы пользователей и заказчиков? 


и Сроки. Можем ли мы передать систему, решающую эти проблемы, 
в заданные сроки. 


= Бюджет. Можем ли мы передать систему способом, который явля- 
ется привлекательным с финансовой точки зрения для заказчиков, 
пользователей, спонсоров проекта и создателей системы? 


в Качество. Можем ли мы передать свойства в состояниях, которые 
подходят для применения пользователями и заказчиками? 


Менеджеры проектов знают, в каком состоянии находится проект 
с точки зрения бюджета, поскольку они могут получить эту информацию 
от финансового директора или бухгалтеров. Менеджеры проектов знают, 
в каком состоянии находится проект с точки зрения сроков, отслеживая 
ход проекта относительно контрольных точек и выполненной работы. Ме- 
неджеры проектов знают, в каком состоянии находится проект с точки 
зрения свойств, поскольку программисты, конфигураторы и инженеры по 
сборке версий могут сообщить, какие свойства реализованы. Лучшие мето- 
ды организации работ в создании программных систем и в управлении 
проектами, применяемые компетентными специалистами, дают возмож- 
ность менеджеру проекта четко разобраться в трех из четырех элементах. 
Но как менеджеры проектов могут пролить свет на четвертый элемент? 


и Фрагменты этой главы впервые появились в журнале "5о/їшате Теѕйпр апа Оиайу 


Кпріпеетіпр", Уофите 2, Іѕѕие 2 (Маг/Арг 2000). Я благодарю Брайана Лоуренса, Брайана Ма- 
рика и Элайн Уэмбек за их помощь в редактировании этой статьи. 
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Часть ответа наэтот вопрос приведена в предыдущей главе. При помо- 
щи отчетов об ошибках мы информируем проектную группу о возникно- 
вении ситуаций, где ответ на вопрос о качестве отрицательный — система 
не подходит для использования таким способом. Слишком часто менед- 
жеры проектов вынуждены работать в неведении относительно более 
широкого вопроса о качестве, особенно в сравнении с другими элемента- 
ми проекта. Я уверен, что эта диспропорция является одной из причин 
того, что страдает качество продукта. 

В главе 1 отмечалось, что успешный процесс тестирования должен 
предоставлять информацию, которая позволяет компании ‘управлять 
рисками качества системы. Эта информация, передаваемая точно, свое- 
временно и в доверительной манере, группе управления проектом, осве- 
щает четвертый элемент проекта - качество. В этой главе я предлагаю по- 
смотреть, как происходит раскрытие четвертого элемента проекта и как 
мы может наилучшим образом выступать в роли прожекторов и носите- 
лей этого знания для проекта . 


Процесс подготовки отчетов 
о результатах тестирования 


Общий процесс подготовки отчетов о результатах тестирования, пока- 
занный в Процессе 11, описать легко. Тот же процесс применим и для по- 
лучения обычных отчетов о ходе проекта, и для анализа критических со- 
стояний или особых событий, хотя, по всей вероятности, вы будете 
адресовать отчеты разным аудиториям и отвечать на разные вопросы. 

Например, в проекте разработки Интернет-приложения я представ- 
лял совокупность графиков хода тестирования на еженедельных совеща- 
ниях по проекту тестирования. Однако дважды в неделю у нас проходило 
совещание по разбору ошибок, где мы принимали сложные решения о 
том, какие ошибки исправить/отложить, используя отчет, в котором пе- 
речислялись краткое наименование, серьезность, приоритет и дата под- 
готовки отчета по всем открытым ошибкам, начиная с момента последне- 
го совещания. 

В одном случае мы провели специальное совещание, посвященное ана- 
лизу результатов выполнения некоторых тестов производительности 
и сравнению полученных результатов с ранее сделанными прогнозами 
производительности на основе статического и динамического моделиро- 
вания. На этом совещании использовалось множество подробных графи- 
ков, показывающих производительность системы в разных условиях, 


Сравнение тестирования с прожектором приведено в книге Сема Канера, Джеймса Баха 
и Брета Петтикорда "І ез5дтя Геатей т Зойшате Тейт”, в которой они пишут, что “[тестиров- 
щики] — это прожекторы проекта”. Джонатан Бах, брат Джеймса Баха и менеджер тестовой 
лаборатории ЗайзНсе, имеет персональную табличку с надписью ТЕЗТЕК (тестировщик). 
Эта табличка — элемент памятной серии о маяках штата Вирджиния, на которой изображе- 
ны три маяка с надписью “Храните негасимый свет”. Мне особенно нравится сравнение тес- 
тирования смаяком, поскольку свет маяков помогает лодкам обойти скалы точно так же, как 
разумное тестирование не допускает попадания проектов на мель. 
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и они сравнивались с таблицами ожидаемой производительности, полу- 
ченной при помощи моделирования. 


Процесс 11. Процесс подготовки отчетов о результатах тестирования! 


№ этапа Этап Выполнено? 


1. Определить аудиторию, которая обычно включзет всех лиц, а 
заинтересованных в процессе тестирования и в качестве сис- 
темы. Определить цели проекта. 


2. Определить результаты, которые должны быть представлены. О 
Обычно это информация, которая должна отвечать на вопро- 
сы аудитории о тестировании, особенно о том, что означают 
результаты тестирования для целей проекта. 


3. Отобрать измерения и составить отчеты и графики, которые о 
отвечают на поставленные вопросы. 


4. Представить результаты тестирования аудитории в соответст- О 
вии с требованиями. 


5. При необходимости уточнить формулировки отчета и виды О 
графиков, а также способ подачи информации аудитории, ка- 
ждому заинтересованному лицу в отдельности и проекту в це- 
лом, повторив этапы 1 — 4. 


Каждое совещание имеет свою аудиторию с отличающимися потреб- 
ностями в информации, с разными вопросами. Я использую в качестве 
темы нашего примера еженедельную отчетность о ходе тестирования, но 
прошу иметь в виду, что этот процесс применим и кдругим типам отчетов 
о результатах тестирования. 

Несмотря на линейную последовательность задач, отчетность о ре- 
зультатах часто является наиболее сложным процессом, с которым стал- 
киваются специалисты-тестировщики в любом проекте. Чтобы гото- 
вить эффективные отчеты о результатах тестирования, тестировщики 
должны обладать тремя качествами. Во-первых, они должны быть спо- 
собны получать глубокие знания о ходе тестировании в целом, о тенден- 
циях и следствиях обнаруженных группой тестирования ошибок и о ре- 
зультатах тестирования в настоящий момент. Во- вторых, они должны 
владеть навыками устной и письменной речи, в том числе для передачи 
сложных и неприятных сообщений. В-третьих, они должны обладать на- 
выками дипломатии для поддержания общего ощущения доверия груп- 
пе тестирования и информации, которую они предоставляют, особен- 
но, когда их сообщения указывают на то, что проект в опасности. 
Теперь посмотрим, как тест-менеджер проекта “Суматра” Джамал Браун 
достигает результата. 


Некоторые читатели узнают в этом описании вариацию парадигмы цель-вопрос- 
измерение Виктора Бэзили. Хороший источник онлайновой информации об этом методе 
можно найти в статье Розенберга и Хьятта “Оеуеюр!ав а Зассезз В! Менлсз Рговгат” по адре- 
су ѕаїс.рзѓс.паѕа.роу /ѕиррогг /іпаех.Мті. 


432 


Часть ІУ. Совершенствование 


9 сос оянии транспортного средства, не е отвлекая. его от вла. за чо 
рогой: и движением, Термин“ система: сбалансированных | показателей” 1037 
‚что при АННО Ре диаграммы или и график такого 


Джамал определяет содержимое 
инструментальной панели и отчеты 
о результатах тестирования большой сборки 


В нашем гипотетическом примере вернемся к тому моменту, когда Джа- 
мал готовил план тестирования. 17 сентября Джамал разослал черновик 
плана тестирования по электронной почте. Он также отправил предла- 
гаемый набор графиков для отчетности о ходе работ по тестированию, 
которые он назвал инструментальной панелью тестирования. 

Он направил это сообщение ключевым участникам проекта “Суматра”, 
заинтересованным в тестировании. В этот список вошли вице-президент 
поддержки разработок Джон Албертсон, вице-президент системных разра- 
боток Гарольд Джоунз, вице-президент по продажам Сайсли Райс, менед- 
жер разработки новой версии Дженни Кауфман, менеджер по маркетингу 
продукта брееду\тиег Кейт Эрнандес, менеджер системных операций 
и администрирования Кейт Ли и менеджер подготовки версий Ясухиро 
Канагава. Эти семь человек совместно с менеджером по комплексному и 
системному тестированию Джамалом Брауном и вице-президентом по фи- 
нансам (ведущей учет в проекте) Сандари Копленд образовали группу 
управления проектом “Суматра", согласно описанию в разделе “Ключевые 
участники» плана проекта. За исключением Сайсли и Сандари, которые 
приглашались по необходимости, группа управления проектом “Суматра» 
собиралась еженедельно для обсуждения хода проекта. 

Цели проекта были определены в разделе “Резюме плана проекта” пла- 
на проекта “Суматра”. 

Ознакомившись с планом проекта “Суматра”, Джамал знал аудиторию 
и цели проекта. 


№ этапа Этап Выполнено? 


1. Определить аудиторию, которая обычно включает всех лиц, М 
заинтересованных в процессе тестирования и в качестве сис- 
темы. Определить цели проекта. 
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План проекта озвучивает цели проекта, в том числе цели тестирова- 
ния. Для того чтобы помочь аудитории понять, достигнуты ли эти цели, 
Джамал должен ответить на четыре глобальных вопроса. 


1. В каком состоянии находится качество системы "Суматра", если из- 
мерять его при помощи результатов тестирования? 


2. Где мы находимся с точки зрения покрытия критических рисков 
качества системы, и что сообщают нам результаты тестирования об 
оставшихся рисках? 


3. Идет ли проект тестирования гладко и эффективно? 
4. Удается ли выполнять запланированные тесты в срок? 


Первые два вопроса относятся преимущественно к системе, в особен- 
ности к изменению ее качества во времени. А два заключительных вопро- 
са больше касаются процесса, в первую очередь проблем сроков и бюдже- 
та. Тем не менее, Джамалу было известно из опыта, что качество системы, 
переданной группе тестирования, сильно зависит от способности группы 
выполнять запланированные тесты в срок и в рамках бюджета. Поэтому 
при подготовке отчетов о ходе тестирования Джамал должен был дать от- 
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веты на эти четыре вопроса при помощи четырех таблиц, которые не- 
сложно построить и понять. 


№ этапа Этап Выполнено? 


2. Определить результаты, которые должны быть представлены. ы 
Обычно это информация, которая должна отвечать на вопро- 
сы аудитории о тестировании, особенно о том, что означают 
результаты тестирования для целей проекта. 


Совместно с группой управления проектом Джамал установил графи- 
ки хода работ и отчеты о ходе тестирования. Они отобрали несколько 
графиков на основе материалов, применявшихся Джамалом в предыду- 
щем проекте $рееду\Мгиег 3.0. Теперь вернемся ктестированию большой 
сборки. 

Последний раз мы видели Джамала в субботу, 21 декабря. Групна тес- 
тирования только что завершила первый полный цикл тестирования. 
Джамал обновил отчет о результатах тестирования. Он отправил по 
электронной почте набор графиков и инструментальную панель тести- 
рования группе управления проектом, а также занес их в проектный ре- 
позиторий. 

Утром в понедельник, 23 декабря, Джамал представлял отчет о ходе ра- 
бот на еженедельном совещании, посвященном ходу работ в проекте. 
Джамал заметил, что на совещание пришли генеральный директор 
боймаге Саѓеѓегіа Раджеш Гупта, менеджер технической документации 
Речел Вудз и менеджер поддержки пользователей Косимо Неграев, атак- 
же Сайсли Райс и Сандари Копленд. Это хорошо, подумал он, поскольку 
это первое совещание, на котором можно сделать выводы о состоянии 
большой сборки. Однако никто из пяти новых членов совещания не уча- 
ствовал в определении инструментальной панели тестирования. Джамал 
отметил для себя, что нужно будет рассказать про саму инструментальную 
панель, когда он будет говорить о ходе тестирования. 

Ход тестирования был третьим вопросом в повестке дня, после отчета 
Дженни Кауфман о ходе разработки и доклада Ясухиро Канагавы о подго- 
товке версий. Когда они завершили свои выступления, Кейт Эрнандес, 
председательствовавшая на совещании, обращаясь к Джамалу, сказала 
сулыбкой: “Итак, Джамал, вот момент, которого мы все ждали. Каквыгля- 
дит большая сборка с точки зрения качества? 

Джамал, который только что присоединил свой ноутбук к проектору, 
открыл титульный слайд “Состояние комплексного и системного тести- 
рования. Инкремент 3 (большая сборка). Сборка 1”. 

“Итак, — начал он, — прежде всего я бы хотел выразить признатель- 
ность сотруднице группы Кейта Ли, который сделал все возможное и не- 
возможное для того, чтобы цикл состоялся. Петра любезно согласилась 
прийти в субботу и помочь тестировщикам, а затем помогла мне устано- 
вить новую версию по окончании тестового цикла. Кейт, пожалуйста, по- 
благодари Петру от моего имени”. 

“Сделаю, — ответил Кейт. 

Джамал начал отчет о ходе работ следующими фразами: “Вы спраши- 
ваете, как там большая сборка? Чтобы дать ответ, я покажу четыре тради- 
ционных графика, которые, в честь наших гостей, я буду пояснять по 
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меретого, как мы будем их исследовать. Я также готов по окончании сове- 
щания более подробно рассказать о любом из графиков”. 

“В целом тестирование идет хорошо. Но есть ряд существенных сооб- 
ражений. Я скажу об этом, когда мы будем рассматривать инструменталь- 
ную панель с результатами тестирования”. 

“В ходе начального обсуждения вопроса о том, какую информацию 
должно предоставлять тестирование, мы пришли к соглашению, что еже- 
недельные отчеты о ходе работ по тестированию должны давать ответы 
на четыре вопроса, — сказал Джамал, переходя к следующему слайду (см. 
рис. 15.1). “Во-первых, в каком состоянии находится качество системы 
“Суматра”, если измерять его при помощи результатов тестирования? От- 
вет на этот вопрос дает итоговая кривая на этом графике”. 

“График показывает среднее число вновь открываемых и закрывае- 
мых ежедневно отчетов об ошибках для каждого тестового цикла, а также 
среднее число незакрытых отчетов об ошибках”. 

“Незакрытых? — прервал его Раджеш. 

“Это разница между общим числом открытых и закрытых отчетов об 
ошибках, — пояснил Джамал. Раджеш кивнул в ответ. 

“Этот график мог бы выглядеть как множество мелких символов, боль- 
шинство которых соответствуют естественному отклонению процесса, 
поэтому я показываю средние значения ежедневных цифр вместо самих 
ежедневных цифр. Поскольку мы получаем версии еженедельно, здесь 
также представлены ежедневные средние значения открытых, закрытых 
и незакрытых ошибок для каждого тестового цикла, в котором выполне- 
ны все тесты для каждой версии. 

Кроме того, здесь показано общее число открытых и закрытых отчетов 
об ошибках, а эти две кривые — ежедневные итоги. Неровности обуславли- 
ваются процессом тестирования. Скачки в общем числе открытых ошибок 
в пятницу происходят из-за исследовательского тестирования, в ходе кото- 
рого обнаруживается больше ошибок, чем при помощи плановых скриптов. 
Скачки в понедельник, а иногда и во вторник в общем количестве закрытых 
ошибок происходят благодаря успешному проверочному тестированию ис- 
правлений. Я показываю общее количество и средние значения за неделю 
в разных масштабах. Понятен ли смысл графика?” Все кивнули. 

“Хорошо, — Джамал сделал паузу, а потом продолжил. — Итак, график 
показывает нам несколько моментов, связанных с качеством. Во-первых, 
количество вновь обнаруженных ошибок остается значительным, но 
управляемым источником риска в проекте. Большое количество вновь об- 
наруженных ошибок должно ожидаться в этой точке проекта, поскольку 
появляется новая функциональность. Далее, количество новых ошибок 
стабильно в течение последних четырех недель и колеблется между 20 
и 30 вдень. Для управления наплывом новых ошибок я предлагаю не пере- 
давать разработчиков, завершивших программирование новых свойств 
“Суматры”, в новые проекты разработки, как это происходило в недавних 
проектах. Я предлагаю оставить всех разработчиков, в настоящее время 
занятых в проекте “Суматра”, на обозримый период для исправления 
ошибок. 

Во-вторых, количество исправленных и отложенных ошибок выгля- 
дит неплохо. Общее число закрытых отчетов об ошибках незначительно 


Среднее количество отчетов об ошибках (по циклам) 


250 


Фазы комплексного и системного тестирования проекта “Суматра” 
Анализ проблем качества системы 


Исследовательское тестирование приводить. 
к обнаружению большего, чем обычно, | ., 
числа ошибок, по пятницам | 


Прогнозируемое число ошибок комплексного | 
и системного тестирования будет обнаружено | 
к плановой дате завершения проекта 21/3 | 


ж 


День Благодарения | | з 
\ роверочное тестирование исправленных ошибок 
в каждой новой версик приводит к скачкам кривой 
[ост зарыта их 
| наторинам 


10/21 ^ 11/4 11/18.. 12/2 12/16 12/30 из 1/27 2/10 2/24 3/10 


Дата открытия/закрытия 


ЮЧІ вания 
Начало комплексного тестирования 7/10 
Начало системного тестирования 21/10 
Завершение комплексного тестирования 14/2 
Завершение системного тестирования 21/3 


1750 


1250 


Итого их сх 


1000 


- Среднее количество открытых ежедневно 

+ Среднее количество закрытых эжадиеано 

ж Среднее количество незакрытых ежедневно 

250  —— Общее количество открытых вжедневно 
—- Общев количество закрытых ежедневно 


КВ. В число закрытых ошибок 
эключены отложенные. 


Рис. 15.1. Оценка качества, представленная на графике открытых и закрытых ошибок 


әиневаоаіонәтаәаод ‘ЛІ член 
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отличается от общего числа открытых отчетов. Незакрытые ошибки сей- 
час находятся под контролем, причем среднее число ежедневно закры- 
ваемых ошибок превосходит количество ежедневно открываемых оши- 
бок в течение последних трех недель. В результате сильно сократилось 
число незакрытых ошибок, которое выглядело настораживающим в по- 
следние четыре недели. 

В-третьих, чтобы быть предельно объективным, скажу, что некоторые 
из незакрытых ошибок временные. Количество незакрытых ошибок 
и разрыв между кривыми открытых и закрытых ошибок рисует чрезмер- 
но пессимистичную картину. Обе кривые растут в течение недели, по- 
скольку многие исправления ошибок включаются в следующую сборку, 
ожидая тестирования и подтверждения закрытия. Я провел анализ, кото- 
рый показывает, что в среднем ошибка откладывается или закрывается 
в течение 12 дней после появления отчета о ней. Это означает, что боль- 
шая часть ошибок будет исправлена в одной из следующих двух версий. 
И ошибки действительно исправляются. Только примерно одна ошибка 
из 20 не проходит проверочное тестирование, и ни один отчет об ошибке 
не проходит проверочное тестирование более чем дважды”. 

"Хм, — сказала Сайсли, задумчиво проводя рукой по волосам, — ты мо- 
жешь отслеживать число повторно открываемых ошибок?” 

“Да, наш инструмент управления дефектами собирает эту информа- 
цию, которая также очень полезна”. 

“На моей предыдущей работе мы называли это “степенью рецидива, — 
сказала она с улыбкой. 

"Не хочу обидеть твоих бывших коллег, Сайсли, но я стараюсь по воз- 
можности избегать таких потенциально сильных выражений”. 

“Между прочим, мы это ценим, — вставила Дженни. 

Джамал с улыбкой посмотрел на Дженни и продолжил свой доклад: 
“Наконец, вы можете видеть, что мы уже слегка перевалили через полови- 
ну прогнозируемого общего числа ошибок, которое равно 2000. Мы вы- 
полнили почти все тесты по крайней мере один раз, поэтому, вероятно, 
получим несколько меньшее число ошибок. Другими словами, система 
оказалась лучше, чем ожидалось”. 

“Приятно слышать, — пробормотала Кейт Эрнандес. 

“Да, приятно, — согласился Джамал, — но неудивительно. Напомню, 
мой прогноз делался на основе исторических данных предыдущих проек- 
тов в5оймаге Саѓеѓегіа. Мы внесли некоторые усовершенствования в про- 
цесс по итогам последнего проекта, поэтому и получаем чуть лучшие ре- 
зультаты”. 

“Я очень надеюсь на это, — шепнул Гарольд. 

Джамал согласно кивнул и перешел к следующему слайду (см. рис. 15.2). 
“Следующий вопрос, на который может ответить тестирование: выполни- 
ли ли мы тесты, нацеленные на проверку рисков системы качества, и что 
нам говорят эти результаты об оставшихся рисках? Данный график обоб- 
щает наше представление о современном состоянии этих областей риска. 

В начале проекта я содействовал проведению анализа рисков с при- 
влечением сотрудников разных направлений, в котором участвовали 
многие из сидящих в этой комнате. Мы определили риски и расставили 
приоритеты для различных возможных проблем качества. Мы сопостави- 
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ли соответствующие уровни тестирования на основе уровней техниче- 
ских и бизнес-рисков”. 

“Джамал, не мог бы ты напомнить о двух типах рисков? — попросила 
Сайсли. 

“Конечно, — ответил Джамал. — Технический риск — это вероятность 
существования ошибки в самой системе и ее влияния на систему. Бизнес- 
риск — это вероятность того, что данная ошибка окажет влияние на рабо- 
ту пользователей и заказчиков, и вероятность влияния этой ошибки на 
пользователей и заказчиков. Понятно? 

“Конечно, — улыбнулась Сайсли. — Спасибо, Джамал”. 

“Пожалуйста, — Джамал продолжил. - В ходе проектирования и разра- 
ботки тестов мы количественно оценивали связь между каждым тесто- 
вым сценарием и каждым отдельно взятым риском качества. Связь между 
тестовым сценарием и риском качества может быть сильно, средней, сла- 
бой или несуществующей, что мы представили числами 9, 3, 1 и 0 соответ- 
ственно. Завершив первоначальное проектирование и разработку тес- 
тов, мы смогли вычислить общее покрытие каждого отдельного риска 
качества и просуммировать его по категориям рисков. Используя эти 
цифры для каждой категории рисков, мы можем сказать, какое значение 
покрытия будет получено при выполнении 100% запланированных тес- 
тов относительно категории риска качества. Серые столбцы на графике 
показывают текущий процент тестов, выполненных для каждой катего- 
рии рисков качества. Разумеется, каждый серый столбец должен достичь 
100%, хотя пропущенные тесты и исследовательское тестирование могут 
дать нам чуть меньший или чуть больший результат”. 

“Что с математической точки зрения означает чуть меньше и чуть 
больше? — спросила Сандари. 

“Диапазон плюс-минус 10%, вероятно, был бы приемлем, — ответил 
Джамал. — Я был очень осторожен в оценках, поэтому ожидаю, что мы 
достигнем 100% покрытия по большинству рисков, и только немногие бу- 
дут покрыты меньше, чем на 95%. Поскольку мы повторяем каждый тест 
примерно от двух до семи раз в рамках процесса регрессионного тестиро- 
вания, даже такое низкое покрытие, как 50%, будет указывать на то, что 
каждый тест был выполнен по крайней мере однажды". 

“А что если, не дай Бог, сроки будут отложены и будут проведены два 
дополнительных цикла тестирования? — продолжала Сандари. 

“В этом случае мы превысим покрытие. Я подсчитал числовое значе- 
ние покрытия, которое представляет 100%-ное запланированное покры- 
тие для каждого риска качества, на основе тестов, которые мы планирова- 
ли выполнить за день, когда мы начали первый цикл комплексного 
тестирования. Если мы добавим тесты, то увеличим покрытие. Это уже 
произошло с определенной частью исследовательского тестирования, 
которое увеличило покрытие для некоторых рисков. — Джамал с любо- 
пытством осмотрел присутствующих. — Понятны ли проблема тестового 
покрытия и его графическое представление?” Все закивали. 

“Итак, выполняя тесты, мы находим ошибки, — продолжал Джамал. — 
Отчет о каждой ошибке мы классифицируем по категориям рисков каче- 
ства. Это позволяет нам понять, где мы обнаруживаем ошибки с точки 
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зрения нацеливания тестов на проверку рисков качества. Белые столбцы 
на графике показывают процент ошибок по категориям”. 

“Таким образом, эти столбцы никогда не покажут 100%? — спросил 
Раджеш. 

“Верно, — ответил Джамал. — Они дадут 100% все вместе, но отдельный 
столбец может достичь 100% только в очень маловероятном случае, когда 
мы будем находить ошибки, относящиеся только к одной категории рис- 
ков качества”. 

“Позвольте мне пройти по тестовому покрытию и обнаруженным 
ошибкам для каждого риска качества слева направо. Первые четыре пары 
столбцов говорят нам одно и то же про первые четыре области рисков. 
Нагрузка, функциональность, обработка ошибок и надежность покрыты 
примерно наполовину выполненными тестами и являются наиболее зна- 
чительными источниками ошибок. Вместе на них приходится примерно 
половина всего количества ошибок. Итак, мы выполнили довольно много 
тестов в этих областях и нашли много проблем, но мне кажется, что мы 
этого и ожидали. Мы можем ожидать, что найдем еще некоторое количе- 
ство проблем в этих областях, но не думаю, что там скрываются какие-то 
большие сюрпризы. Как яужеупоминал ранее, мы должны сохранить лю- 
дей, занятых исправлением ошибок, чтобы управлять проблемами, кото- 
рые мы уже нашли в этих областях и которые будем продолжать нахо- 
дить, но, по моему мнению, мы сейчас хорошо представляем себе эти 
риски. 

“Будем продолжать находить? — спросил Раджеш. 

“Да, — пояснил Джамал, — обычно там, где обнаружено много ошибок, 
вы найдете еще ошибки. Правило, справедливое для огромного числа 
проектов, заключается в том, что ошибки обычно концентрируются оп- 
ределенным образом. Один из вариантов, когда ошибки скапливаются в 
определенных категориях рисков качества. Таким образом, я полагаю, 
что тестирование позволит найти примерно половину остающихся оши- 
бок именно в этих четырех областях”. 

“Интересно, — прокомментировал Раджеш. — Я было подумал, что 
вы должны в каждой категории в определенный момент “вычерпать 
все до дна”. 

“Да, это действительно кажется логичным, — согласился Джамал. — Од- 
нако правило скопления ошибок, противоречащее интуиции, давно на- 
блюдается тестировщиками программного обеспечения”. 

“Перейдем к следующей области риска. Тестирование интерфейсов 
в основном уже завершено. Мы нашли несколько ошибок, большинство 
в настоящее время закрыто”. 

“Поэтому комплексное тестирование было успешным? — спросила 
Кейт Эрнандес. 


Это правило, на которое содержатся намеки в книге Фреда Брукса “Мифический человеко- 
месяц", впервые, насколько мне известно, было сформулировано в явном виде Гленфордом 
Майерсом в “Искусстве тестирования программ”. Позднее Роберт Сабурин и Ким Дэвис вы- 
полнили интересную работу по исследованию скопления ошибок и по применению этих 
знаний в тестировании. Прочитайте их статью “Ехріогіп, О15соуепир апа Ехгегтіпацпя 
Вир Сшяегз іп Мер АррЦсаНопз, которая доступна на ми\.ап!ир.сот. 
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“Комплексное тестирование будет продолжаться еще два месяца, пока 
мы не получим последний инкремент. Однако уже сейчас можно сказать, 
что оно было успешным, поскольку дало нам много возможностей для ис- 
правления ошибок, и мы использовали эти возможности. Фаза системно- 
го тестирования не проходила бы столь гладко сейчас, если бы не было ус- 
пешного комплексного тестирования и исправления найденных ошибок, 
в котором мы все участвовали, — заключил Джамал. 

“Работа основных функций и сопровождение проверены столь же под- 
робно, как и первые четыре категории рисков, с чуть меньшим числом об- 
наруженных ошибок. Меня устраивает ситуация в этой области рисков, 
снова с учетом того, что мы оставим основные ресурсы для исправления 
ошибок, которые, я уверен, мы найдем в этих областях. 

Совместимость и качество данных протестированы довольно подроб- 
но. Я не ожидаю никаких неприятных сюрпризов в этих областях, хотя 
мы обнаружили и еще найдем серьезные ошибки в области качества дан- 
ных”. 

Дженни кивнула и добавила: “Да, тестирование качества данных, про- 
веденное твоей группой, практически спасло нас. Мы никогда бы не на- 
шли некоторые из ошибок в ходе модульного тестирования”. 

“Согласен, сложность тестовой среды и некоторые усложненные сце- 
нарии использования системы в области качества данных имели большое 
значение, — ответил Джамал и продолжил свой доклад. 

“Производительность и безопасность проверены так же подробно, 
как и первые четыре элемента, но ошибок было найдено вчетверо мень- 
ше. Я думаю, мы выглядим неплохо в этих областях риска, хотя я настаи- 
ваю на завершении всех запланированных тестов. С точки зрения бизнес- 
рисков эти компоненты очень важны. Даже если бы мы не нашли до сих 
пор ни одной ошибки, я бы все равно предложил продолжить тестирова- 
ние этих областей”. 

“Ты целиком и полностью прав, Джамал. Лучше переборщить с тести- 
рованием производительности и безопасности, — согласился Косимо. — 
Эти две области, пожалуй, наиболее болезненно отражаются на звонках 
в нашу группу поддержки”. 

“Правда? — спросил Раджеш, удивленно поднимая брови. 

“Да, — ответил Косимо. — Я не могу привести никаких цифр, однако 
скажу, что по крайней мере раз в неделю уменя возникают серьезные про- 
блемы в одной или в обеих этих областях”. 

“Понимаю, что это не входит в нашу повестку дня, — извинился Рад- 
жеш перед Кейт и Джамалом, — но, — продолжил он, обращаясь к Коси- 
мо, — не мог бы ты классифицировать звонки в службу поддержки в соот- 
ветствии со списком рисков качества Джамала и сообщить мне, что 
получится? 

“Конечно, — ответил Косимо. — Мы можем запланировать проведение 
такого анализа после выхода версии Суматры, чтобы посмотреть, что 
происходит сточки зрения анализа рисков, но мы также можем начать де- 
лать это прямо сейчас”. 

“Прости за то, что прервал тебя, Джамал, — сказал Раджеш с улыбкой, 
завершая обсуждение с Косимо. 
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“Я думаю, что это было вполне к месту, — ответил Джамал и продол- 
жил. — Исследование удобства использования практически завершено. 
Мы думаем, что здесь не осталось ничего опасного. Отличная работа тво- 
ей группы по разработке интерфейсов пользователей, Дженни”. 

Дженни кивнула, улыбаясь. 

“Тестирование локализации только началось, — продолжал Джамал. — 
Пока мы не обнаружили ничего плохого, но мы еще не проделали доста- 
точной работы. Спросите меня через пару недель, и я буду гораздо лучше 
представлять ситуацию. Сейчас же могу лишь сказать, что “мы не знаем, 
чего мы не знаем”. 

“Две недели? — спросила Сандари. 

“Да, — ответил Джамал, —мы нехотим тратить кучу денег на повторное 
тестирование локализации, поэтому запланировали только два раунда 
ближе к концу. Эти тестировщики не работают за небольшую плату”. 

“А нельзя было сделать это самим? — упорствовала Сандари. 

“Мы могли бы это сделать внутри компании, но мне бы потребовался 
значительно больший бюджет, чтобы нанять специально выделенный 
штат полиглотов и экспертов по стандартам. Языки, совместимость со 
стандартами, визуальное представление дат, времени, валюты и т.д. 
и т.п. — это все труднее сделать, чем кажется”. 

Сандари пожала плечами и признала свое поражение, сказав: “Я дога- 
дываюсь, что это не бесплатный обед”. 

“Конечно не бесплатный шведский стол, будь уверена, — с улыбкой 
подтвердил Джамал. Он продолжал: “Тестирование документации выпол- 
нено наполовину, ничего серьезного там не обнаружено, верно, Речел? 

“Верно, — согласилась менеджер документации. 

“Обработка дат и недостаточная конкурентоспособность также, похо- 
же, имеют невысокий риск, поскольку мы уже предприняли основные 
шаги по его снижению, — подытожил Джамал. — Вот где мы находимся 
с точки зрения рисков. Есть ли вопросы? 

Увидев, что нет вопросов, Джамал перешел к следующему графику (см. 
рис. 15.3). “Следующий вопрос к тестированию — измерение качества 
продукта и хода проекта тестирования: сколь гладко и эффективно идет 
проект тестирования? 

“Невижутого, что говорило бы нам о качестве системы, — прокоммен- 
тировал Раджеш. 

“Если тестировщики не могут рационально и производительно прой- 
ти тестовые сценарии для проверки поведения системы, которые, как 
правило, являются аналогией действий пользователей, то каким же ока- 
жется опыт пользователей и заказчиков? — ответил Джамал. 

“Да-а-а-а ...“ — только и смог сказать Раджеш, потирая ухо и заново изу- 
чая график. 

“Я показываю, сколько часов в неделю отводится на выполнение тес- 
тов, исходя из запланированного для каждого цикла тестирования. Это 
непрерывные линии. Заметьте, что у нас не планируется работа в выход- 
ные, в результате чего у этих линий есть разрывы. Прямоугольники пока- 
зывают, сколько часов в день фактически тратится на тестирование. Ко- 
личество часов учитывается только тогда, когда тест завершен (прошел, 
не прошел или предупреждение), и никаких дополнительных часов не мо- 
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жет бьть потрачено на зтот тест до тех пор, пока вновь не будет заплани- 
ровано его выполнение”, — сказал Джамал. 

“Это означает, что часы на выполнение теста могут быть распределе- 
ны больше, чем на один день, но будут учтены только в последний день? — 
спросил Раджеш. 

“Верно, — сказал Джамал. — Возможно, это не совсем верно, но это уп- 
рощает учет. Поскольку средние затраты на выполнение теста меньше, 
чем один день, картина достоверная”. 

“Понятно”, — согласился Раджеш. 

“Как вы видите из графика, раунды 2 и 4 были в целом не очень эффек- 
тивны, то же можно сказать о раунде 5. Относительно большое число тес- 
тов завершилось неудачей в эти раунды, что привело к тому, что продол- 
жительность раундов была несколько большей. Мы полагаем, что это 
также отражает общую неуклюжесть продукта, связанную с количеством 
незакрытых ошибок. По мере того как число незакрытых ошибок сокра- 
щалось, мы видим, как график начал сходиться в области между пунктир- 
ными линиями, ограничивающими “нормальную” эффективность, — под- 
вел итог Джамал. 

“Таким образом, этот контрольный график — именно то, что ты хотел 
сказать? — спросил Гарольд. 

“О, нет, это не контрольный график в смысле статистического управле- 
ния процессом, — быстро ответил Джамал. — Сейчас у меня нет таких дан- 
ных. Пунктирные линии показывают что-то вроде ежедневного отклоне- 
ния, которого я ожидаю оттестовых сценариев, занимающих дни целиком”. 

“Итак, — спросил Раджеш, — сколько тестов в настоящий момент не 
прошли без ошибок? 

“Хорошо, что ты спросил, — сулыбкой сказал Джамал. — Теперь я могу 
перейти к следующему графику (см. рис. 15.4). Этот график дает ответ на 
четвертый и последний вопрос: удается ли выполнить запланированные 
тесты в срок? Он также сообщает нам некоторые сведения о качестве сис- 
темы, хотя и не в явном виде. 

Как и на предыдущем графике, сплошные линии показывают плано- 
вые тесты, а квадратики — фактическое выполнение тестов. Это накопи- 
тельный график, показывающий как плановые, так и фактически цифры 
общего числа выполненных за день тестов для каждого раунда тестирова- 
ния. В конце каждого раунда мы снова начинаем с нуля. Как вы видите, 
квадратики довольно близко подходят к сплошным линиям, т.е. мы до- 
вольно хорошо выполняем запланированные тесты, хотя и немного не- 
эффективно, как было показано на предыдущем графике”. 

“Маленькие минусы показывают число неуспешно завершенных тес- 
тов, а маленькие плюсы - число успешно пройденных тестов, и снова ито- 
говые цифры для каждого раунда. Я ожидаю, что определенное число тес- 
тов будет заблокировано недостающей функциональностью. Вот почему 
первые четыре линии общего числа запланированных тестов короче, 
чем остальные. Праздник Дня Благодарения делает третью линию обще- 
го числа запланированных тестов особенно короткой”. 

“А где на графике Рождество? — спросил Ясухиро. 

“Здесь на лицо плюсы группы тестирования с сотрудниками, относя- 
щимися к разным культурам, — сказал, улыбаясь, Джамал. — Тестировщи- 
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Выполнение запланированных тестовых сценариев 


№ 
У 
5 
№ 
20, 15, 10и5% | з 
ры } кая неделя Рождественские и новогодние б 
б тестов были и і | с Днем Благодарения, А каникулы для некоторых } 
блокированы | З. і Е: и’ } сотрудников группы. | = 
в первых четьрах || АЕ І 
он ПО к ; | В идвале квадратики, 
соответственно, | ц і показиваюцій общее о 
і число выполненных к) 
тестов, должны У 
{ приближаться к линии < 
| общего числа < 
| запланированных тестов. ә 
і Ф 
Е 
Ф 
х 
ч 
—— его запланировано тестов 


а Всего выполнено тестов 
+ Всего успешно пройденных тестов 
7 вого неуспешно занршившкогя тестов 


Тестовых сценариев на раунд 


М.В. Мы планирувм пропускать от 10 до 20 
тестовых сценариев в большинстве раундов, 
поскольку ограничения ресурсов не позволяют 
нам провести тестирование надежности, 
перегрузок, локализации и удобства 
использования в каждом раунде. 


. Ключевые контрольные точки тестирования 


Начало комплексного тестирования 7/10 
Начало системного тестирования 21/10 
Завершение комплексного тестирования 14/2 
Завершение системного тестирования 21/3 


107 10/21 11/4 11/18 12/2 12/18 12/30 113 ‚ МТ но . 2/24 3/10 
| І Даты - 


т р ее 


Рис. 15.4. Выполнение тестов Ё 
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ки, которье не отмечают Рождество, согласились перенести каникульт на 
другое время. Поэтому мы будем проводить тестирование на рождествен- 
ской неделе. Я уже предупредил ключевых участников из других групп, к 
кому могут обратиться за помощью. Дженни, я не знаю, сколько програм- 
мистов будет работать на той неделе, но если немного, то, вероятно, бу- 
дет незначительное увеличение по незакрытым ошибкам в течение оче- 
редных двух циклов, либо программисты догонят по ошибкам, 
обнаруженным в течение рождественской недели”. 

“Мне не повезло, как Джамалу, решить проблему каникул, — ответила 
Дженни. - - Вероятно, будет небольшой разрыв в устранении незакрытых 
ошибок”. 

“Джамал, я не совсем понимаю, почему ты сказал, что график не гово- 
рит о качестве явно, — заметила Сайсли. — Ты показываешь число про- 
шедших и непрошедших тестовых сценариев”. 

“Число тестовых сценариев — штука загадочная, — ответил Джамал. — 
Легко привести случай, когда эти цифры не имеют никакого отношения к 
качеству. Я могу объединить два неудачно завершившихся тестовых сце- 
нария и получить один сценарий, либо я могу разбить один прошедший 
тестовый сценарий и получить два успешных сценария. Я могу добавлять 
тесты по ходу тестирования. Мы редко получаем к концу проекта цифру 
“100% прошло успешно”, поскольку мы обычно принимаем решение не 
исправлять все ошибки, что означает, что некоторые тесты не прошли. 
Поскольку мы как тестировщики занимаемся поиском ошибок, мы стре- 
мимся выполнять тесты, которые находят ошибки. В то же время это оз- 
начает, что процент неудачно завершившихся тестов часто рисует слиш- 
ком пессимистичную картину качества системы. Поэтому некоторое 
число неудачно завершившихся тестов вполне ожидаемо". 

“Каково обычное число неудачно завершившихся тестов при заверше- 
нии системного тестирования? — спросил Раджеш. 

“Не могу точно вспомнить, — ответил Джамал, — но в двух последних 
версиях, по-моему, было 15-20%. Если нужно, я могу уточнить цифру”. 

“Не нужно. И так все довольно ясно, — сказал Раджеш. — Нам еще дале- 
ко до завершения”. 

“Да, сейчас непрошедших тестовых сценариев примерно вдвое боль- 
ше, — ответил Джамал. — Это подводит нас к контрапункту. Сейчас я могу 
довольно быстро показать, что подсчеты тестовых сценариев также име- 
ют некоторое значение для качества системы. Поскольку мы проектиру- 
ем тесты, нацеленные на проверку поведения системы, они имеют неко- 
торое отношение к действиям, которые могуг выполнять пользователи, 
иквариантам поведения, которые пользователи могут наблюдать. Поэто- 
му большое количество непрошедших тестов действительно дает нам ин- 
формацию о качестве системы. Это похоже на живопись в стиле пуанти- 
лизма. Если вы будете смотреть с очень близкого расстояния, то увидите 
точки, которые сами по себе ничего не значат. Как только вы отходите, 
вы начинаете видеть отчетливую картину”. 


№ этапа Этап Выполнено? 
3. Отобрать измерения и составить отчеты и графики, которые 


отвечают на поставленные вопросы. 
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“Что тебя беспокоит, Джамал”, — спросил Раджеш. 

“Во-первых, у нас остается несколько областей значительного риска, 
о которых мы либо знаем недостаточно, либо знаем о наличии в них серь- 
езных проблем. Сейчас мне кажется, что в ближайшие две-три недели эти 
области высокого риска будут протестированы, а обнаруженные ошибки 
будут исправлены. Однако мы должны следить за этим. В ближайшие не- 
дели очень большое значение имеет разбор ошибок, поскольку я думаю, 
что будут найдены новые существенные проблемы. Мы пока еще не подо- 
шли к тому моменту, когда обнаруживают только заключительные не- 
большие ошибки”. 

Раджеш кивнул. 

“Во-вторых, я кратко говорил о застарелых проблемах в Зоймаге 
Саїегегіа, когда мы забирали разработчиков, занятых исправлением оши- 
бок, обнаруженных в ходе системного тестирования, и назначали их в но- 
вые проекты. Это были, как правило, опытные разработчики, которым 
в новых проектах ставились задачи проектирования. В результате ис- 
правление ошибок концентрировалось в руках тех людей, которые неред- 
ко дестабилизировали архитектуру и саму систему, — сказал Джамал. — 
Я не собираюсь обижать группу Дженни. В проекте “Суматра” работает не 
один человек. Но есть разные уровни квалификации. Раньше мы говори- 
ли, что все мы работаем с тривиальными заключительными ошибками, и 
соответственно уменьшали число людей и общую квалификацию персо- 
нала. Но на самом деле мы работали с существенными ошибками, кото- 
рые имели далеко идущие последствия. Это выливалось в большие про- 
блемы, когда нужно было соблюдать сроки, а сложности возникали как 
раз в конце проекта". 

“Замечание принято, — сказал Раджеш. — Продолжай, пожалуйста”. 

“В-третьих, как я говорил, и число неудачно завершившихся тестов, 
и среднее время выполнения тестового сценария пока выше тех значений, 
которые я бы хотел видеть в конце проекта. Я не сомневаюсь, что эти циф- 
ры улучшатся через два месяца, но снова скажу, что за этими индикаторами 
надо внимательно следить. Если к началу февраля они не начнут снижать- 
ся, это будет означать, что у нас есть проблема. Еще раз, это связано с необ- 
ходимостью сохранения подходящей комбинации уровня и квалификации 
персонала в группе Дженни к моменту завершения проекта. 

Наконец, напомню, что суммарная цифра закрытых дефектов на первом 
графике включает в себя ошибки, отложенные до следующей версии, той, 
что появится после Суматры. Их число выросло, а число незакрытых оши- 
бок уменьшилось, поскольку на совещаниях группы управления изменения- 
мимы приняли решение, что ошибки приоритета 2 могут быть отложены”. 

Раджеш вопросительно посмотрел на Кейт и Дженни, которые сидели 
рядом. 

Кейт приняла вызов и сказала: “Я думаю, что пользователи воспримут 
правильно нашу агрессивную политику по откладыванию ошибок. Эта по- 
литика является частью стремления передать версию, которая обладает 
всеми функциональными возможностями высшего и среднего приорите- 
та, вовремя. Реалии таковы, что другим вариантом является незакончен- 
ная финальная итерация, поскольку очень много программистов занято 
исправлением ошибок”. 
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“Мнепонятен этот компромисс, — ответил Раджеш. — Но давайте не бу- 
дем сильно снижать качество и передавать свойства с массой ошибок. Это 
не имеет смысла”. Кейт и Дженни неуспели ничего возразить, Раджеш по- 
вернулся на стуле и бросил взгляд на Джамала: “Итак, господин тест- 
менеджер, каково ваше мнение об этой “агрессивной политике отклады- 
вания ошибок”? 

Джамал посмотрел Раджешу в глаза и сказал: “Не хочу уклоняться от 
вопроса, господин генеральный директор, но я вижу свою основную роль 
в том, чтобы оценивать качество и сообщать о результатах оценки. Я не 
являюсь полицейским качества. Поэтому как господин тест-менеджер я 
остаюсь нейтральным к этой политике”. 

Раджеш почесал бороду и, продолжая пронизывающе смотреть на 
Джамала, спросил: “А что думает господин Джамал Браун как мыслящий 
человек и законный владелец акций компании? 

“Лично я предпочел бы несколько повысить планку качества. Одна- 
ко, — согласился Джамал, — этого всегда хочется. Что я вижу постоянно 
в течение рабочего дня — это проблемы качества. Мы находим 
100—150 ошибок еженедельно. Это искажает мое восприятие, делает 
меня чувствительным к рискам качества системы. Поскольку я сосредото- 
чен на этих рисках, вероятно, я не вижу других. Риски сроков и бюджета, 
которые видят Дженни, Кейт и Сандари, не столь очевидны для меня. 

Честно говоря, Раджеш, — подвел итог Джамал, — я думаю, чтобы опре- 
делить, не занизили ли мы планку качества, тебе придется изучить все 
или, по крайней мере, большое количество ошибок, которые были отло- 
жены. Если у тебя нет времени на это, может быть, Косимо выступит в 
роли твоего полномочного представителя. Если ты или он увидит ошиб- 
ки, которые вас пугают, то, возможно, нам нужно будет прекратить откла- 
дывание исправления ошибок, чтобы слегка приподнять планку. Я не рас- 
полагаю всей информацией о том, как заказчики и пользователи 
отнесутся к нашему продукту с учетом заявлений компании о приорите- 
тах ошибок и об их разборе”. 

“И это ты хотел сказать мне в моем кабинете за закрытыми дверями, 
Джамал? 

“Да”, — твердо ответил Джамал. 

“Хорошо, когда будет следующее совещание группы управления изме- 
нениями? — спросил Раджеш. 

“30-го, в понедельник, — ответила Кейт. “Мы отменили три совещания 
на этой неделе, поскольку не можем обеспечить присутствие сотрудни- 
ков разных групп”. 

“До совещания я просмотрю отложенные ошибки, и я буду на совеща- 
нии со списком ошибок, исправление которых надо будет возобновить, — 
сказал Раджеш. — У нас все с ходом тестирования? 

“Да, — сказал Джамал. 

“Хорошо. Отличная презентация. Очень понятная, — подвел итог Рад- 
жеш. — Что у нас дальше в повестке дня? 


№ этапа Этап Выполнено? 
4. Представить результаты тестирования аудитории в соответст- 


вий с требованиями. 
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Построение успешного процесса подготовки 
отчетов о результатах тестирования 


В нашем примере Джамал использует удобный процесс для еженедельной 
отчетности о ходе тестирования. Что мы можем сказать в общем виде 
о работе группы тестирования и рабочей группы проекта ио преимущест- 
вах, которые они получают от удобного процесса подготовки результатов 
тестирования? 


Своевременная передача полезной, заслуживающей доверия 
информации 


В качестве аналогии процесса тестирования и подготовки отчетов о его 
результатах рассмотрим газету. Газета с обозрением местных новостей 
в других городах, а не в том, в котором вы живете, бесполезна. Газета, не 
рассматривающая финансовые и деловые проблемы, бесполезна для 
управления вашим портфелем инвестиций. Газета на непонятном вам 
языке бесполезна. Газета, которой вы не доверяете, бесполезна. Вчераш- 
няя газета почти бесполезна, а газета месячной давности представляет 
лишь исторический интерес. Я полагаю, что специалисты-тестиров- 
щики, считающие себя репортерами по теме качества, и ведущие тести- 
ровщики и тест-менеджеры, которые считают себя издателями газеты о 
качестве, могут использовать это сравнение для определения направле- 
ния подготовки отчетов о результатах тестирования. 

При обдумывании вопроса по поводу отчетов о результатах тестирова- 
ния следует спросить себя: мы, группа тестирования, готовим нужные от- 
четы, в нужное время, с нужной периодичностью и передаем через подхо- 
дящие каналы? Еще лучше, если вы спросите об этом ваших менеджеров и 
коллег, всех лиц, заинтересованных в процессе тестирования и качестве 
системы. 

Считаю важным последовательное определение информации, которая 
должна быть получена в процессе тестирования, совместно с коллегами и 
руководителями. В нашем примере Джамал построил четыре графика, ко- 
торые составили инструментальную панель проекта тестирования. Эти 
графики были получены в результате следования процессам, определен- 
ным ранее, начиная с целей проекта и ключевых заинтересованных лиц и 
заканчивая отдельными измерениями, представленными графически. 

Одна из сложностей состоит в том, что руководители и коллеги могут 
испытывать затруднения при определении метрик, которые должны из- 
меряться группой тестирования, а вы, по всей вероятности, столкнетесь 
с проблемой отсутствия собственных идей, если впервые занимаетесь 
проблемой организации процесса подготовки отчетов о тестировании. 
К счастью, существует немало хороших источников идей. Одним из них 
является данная глава, а также главы 4 и 5 моей предыдущей книги 
"Мапаріпр іће Тезійпе Росе55, Ѕесопа Ейійот. Стефан Канн в “Мейс; апа Моаеіѕ 
іт 5о|їшате Оцаїйу Епріпеетіпр, 5есопа Еаййот , Борис Бейзер в "Зо/їшате бузієт 
Тезійпе апа Опайу Аѕѕитапѕе и Панкодж Джалот в “СММ іп Ргасійсе" обсужда- 
ют различные метрики тестирования и контроля качества программных 
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продуктов. Анна Эллисон написала полезную статью “Меапіпрѓиі 
Меггісѕ”, которую можно прочитать на уүу.зіскутіпаѕ.сот. Другие инте- 
ресные источники вдохновения перечисляют в библиографическом спи- 
ске и упоминаются в сносках этой главы. 

Джамал представил то, что обычно называют инструментальной пане- 
лью тестированияили системой сбалансированных показателей, т.е. он кратко 
описал ход тестирования. Этот перечень отчетов подходит для совеща- 
ния, посвященного ходу тестирования, но коллеги-менеджеры, возмож- 
но, обратятся за более подробными сведениями. Например, менеджер 
технической поддержки или менеджер разработки, вероятно, захочет 
подробно изучить отчеты об ошибках либо на регулярном совещании, 
либо входе неформального обсуждения. Один вариант не подойдет всем. 
Получатель информации, а не ее создатель определяет ее значимость и 
пользу. 

Точность - это другой важный элемент, характеризующий полезность 
информации. Базовые проектные решения часто принимаются на осно- 
ве результатов тестирования. Должны ли мы задержать выпуск продукта? 
На что надо потратить дефицитные ресурсы в конце проекта? Точным 
должно быть не только представление данных (отчетов об ошибках, ре- 
зультатов тестирования, трассировки покрытия и т.п.) в виде краткого 
отчета (т.е. на инструментальной панели), но и анализ, который прово- 
дится на основе этих данных. Наконец, эффективное озвучивание резуль- 
татов означает, что вся аудитория получила в ходе презентации точное 
понимание смысла отчета о ходе работ по тестированию. 

Когда вы рассказываете о ходе тестирования, вам необходимы навыки 
публичных выступлений для того, чтобы суметь донести смысл ваших 
идей. Одно время я страдал от боязни сцены. Иногда я делал краткие или 


оборонительные комментарии, представляя результаты тестирования 


публично, что приводило к меньшей эффективности моих презентаций. 
Когда я нервничал, я забывал рассказать о ключевых деталях, оборони- 
тельно реагировал на открытые и честные вопросы, демонстрировал 
нервозность, что отвлекало аудиторию. Всему, что я знаю о публичных 
выступлениях, я научился методом проб и ошибок. Я уже много лет рас- 
сказываю о результатах тестирования, а также выступаю на конференци- 
ях, на сайтах для клиентов и на семинарах. Сейчас существует множество 
книг, учебных курсов и компаний, которые помогут вам овладеть оратор- 
ским искусством. Я был бы счастлив, если бы в свое время мог ими вос- 
пользоваться. 

Обычно информацию, поступающую из проекта тестирования, лучше 
всего представить графически, как это сделал Джамал, или при помощи 
таблиц. Широкое распространение и простота использования таких инст- 
рументов, как Мога, Ехсеї, У1510 и Ассеѕѕ (называю только несколько при- 
меров, с которыми я лично знаком), с одной стороны, дают возможность 
провести сложный анализ и подготовить представление информации. 

С другой стороны, применение этих инструментов может привести 
к появлению пугающего числа документов, графиков, таблиц и отчетов. 
Бурный рост псевдоинформации может задавить проект, внутри несуще- 
ственных данных могут прятаться небольшие фрагменты информации, 
критичной для проекта. Число человеко-лет, которые были потеряны, 
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1 Какп тратить эпустую время и деньги а бесполезные отчеты. 


| чего спонсор проекта решил пригласить новую команду консультантов по 
тестированию в лице вашего покорного слуги. Прежде всего я спросил. 

менеджера проекта, какие графики и отчеты из ежеднев 

р стоянии дел она: испалезувт в качестве. ключевых инду 


В тубу. из- за подготовки отчетов, которые: никто не итал; Что еще хуже, 
- проект выполнялся без всех тех многочисленных преимуществ, которые. 

предоставляет программа тестирования. Возврат инвестиций в тестиро-. 
_ вание сократился до обнаружения и исправления ошибок, которое проис-. 


МИ: "Единс енной хорошей новостью в 
- консультанта на 100% были занят 
- Следовательно, работа, которую о! 
‚ ного пакета отчетных документов, 


‚ этом проекте было то, ‘что три. 
‚дготовкой ежедневных отчетов. 
полняли по подготовке 6 бесполез- 
твлекала их ни от каких других дел. 


и число проектов, которые потерпели неудачу из-за того, что их менедже- 
ры рисовали бесполезные таблицы и графики, неизвестно, но, без сомне- 
ния, очень велико. 

Я начал понимать эту проблему, когда стал изучать вопросы дизайна, 
в частности, уеБ-сайтов. Наибольшую помощь оказала отличная трило- 
гия Эдварда Тафта (Едмага Тиќе), посвященная дизайну и представле- 
нию а “Тһе Уізиаї Дізріау орОиатщание проттайот”, “Еплляотте 
трттайот” и “Узи Ехріапайопі" вдохновили меня на более успешную ра- 
ботупо но графиков и отчетов по тестированию. Рекомендую всем 
эти книги. Комментарии Тафта по выбору подходящих цветов, штрихо- 
вок и меток, а также его критика лишних и непонятных значков на графи- 
ках и в диаграммах, оказались весьма полезными для меня. 

Точность данных и информации, эффективные навыки устного обще- 
ния, тщательно продуманные графики, отчеты и другие документы по- 
зволяют сохранять доверие к результатам тестирования. Я также вижу, 
что чем выше поднимаешься по иерархии руководителей, тем больше 
значение имеет подача информации. Я не предлагаю делать информа- 
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цию кричащей. Напыщенные мультимедийные звуки и видеоклипы, вра- 
щающиеся графические фрагменты обычно не информируют, а отвлека- 
ют. Только потратив больше времени для того, чтобы понять 
потребности аудитории в информации, и подготовив действительно ра- 
ботающее и лаконичное представление данных, удовлетворяющее эти 
потребности, можно получить хорошую презентацию. 

Своевременность и периодичность — это также элементы полезности 
результатов и доверия к ним. Коллеги хотят получать самую свежую и ме- 
нее обработанную информацию как можно чаще, а более высокопостав- 
ленные руководители, включая высших, ожидают менее частого поступ- 
ления отчетов о тестировании. Руководители рассчитывают, что отчеты 
будут краткими и информативными. Внимание старших и высших руко- 
водителей к ходу тестирования мне представляется как топливный бак. 
У меня есть ограниченный запас топлива, и я не хочу его израсходовать 
прежде, чем завершится проект. , 

Наконец, выбор правильных каналов для передачи информации ока- 
зывает влияние на полезность, своевременность информации и доверие 
к ней. Возможны следующие каналы для распространения информации: 


= Совещания о состоянии дел в проекте 
ш Совещания по разбору ошибок (Боо сгам1) 


м Внеплановые совещания, посвященные обсуждению критических 
ошибок, препятствующих продолжению работы 


и Совещания группы управления изменениями (см. главу 16) 


= Совещания, посвященные началу фазы тестирования (известные, 
как обзор готовности продукта к тестированию) 


и Совещания, посвященные завершению фазы тестирования 


Совещания по выпуску, поставке версии или принятию решения 
о возможности продолжения работы 


т Телеконференции 
є Электронная почта 
и 
и 


Внутренняя сеть компаний 
Индивидуальные беседы 


Способ, вид, степень детализации и презентация информации могут су- 
щественно отличаться при использовании различных каналов. Что подхо- 
дит для одного канала (полезно, своевременно и укрепляет доверие), может 
совершенно не подходить для других каналов, иногда вызывая серьезные 
проблемы, связанные с доверием к специалистам-тестировщикам. И, наобо- 
рот, внимательное отношение к передаче полезной и своевременной ин- 
формации нужным людям при помощи соответствующих каналов определя- 
ет положительное отношение и укрепляет доверие к вам. 


Связь состояния тестирования с ходом проекта и его влияние 
на будущее проекта 


Другое направлениеукрепления доверия — это увязывание состояния тес- 
тирования и хода проекта в целом, а также планирование шагов по про- 
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движению вперед. Если мы завоевали доверие, люди будут следовать 
предлагаемым шагам, возможно, не в точности, как мы хотим, но мы бу- 
дем оказывать влияние на ход проекта. Если мы не обладаем необходи- 
мым доверием, люди пренебрежительно отнесутся к нашим идеям и не бу- 
дут доверять нашим оценкам хода тестирования и проекта в целом. 

Эффективные отчеты о результатах тестирования — это нетолько точ- 
ные данные. Это не только красивые графики, отчеты и таблицы. Это не 
только вдумчивый и подробный анализ. Это не только уверенная и убеди- 
тельная подача информации. Это не только правильный выбор канала пе- 
редачи. Да, все это вместе — необходимо, но это лишь тактика. Наша 
цель — эффективная передача информации о ходе тестирования лицам, 
заинтересованным в тестировании. Другими словами, информацию спе- 
циалиста-тестировщика слушают, ее слышат, понимают и, если этого тре- 
бует информация, действуют согласно ей. 

Мой опыт показывает, что для обеспечения эффективной передачи 
информации о результатах тестирования, я должен обернуть ее в такую 
упаковку, чтобы увязать с проектом и его целями. Например, что я могу 
сказать, если цели проекта — поставка развлекательной видеоигры с неко- 
торым набором нетривиальных свойств в виде архивированной приклад- 
ной программы для Рур в рамках прибыльного бюджета и разумных сро- 
ков? И что я должен сказать, если цели проекта — поставка бездефектной 
системы для проведения лучевых процедур больных раком? Очевидно, 
что одинаковое представление результатов тестирования, даже количе- 
ственно одинаковых результатов, — это не просто плохая идея, это этиче- 
ски неприемлемо. 

Кроме того, я должен спросить себя, чего ожидает компания от завер- 
шенного проекта тестирования и что хочу сделать я. Отчет о результа- 
тах — это то место, где в письменной или устной форме, графически или 
при помощи некоторой комбинации методов озвучиваются достижения. 
Если одно из достижений, которого я пытаюсь добиться, может заставить 
проектную команду действовать на основе полученной от меня информа- 
ции, т.е. может оказать влияние на ход проекта, то отчет о результатах — 
это главный этап процесса влияния. 

Если это так, я должен предусмотреть, как группа проекта отреагирует 
на результаты, о которых я доложу. Нельзя допускать, чтобы отсутствие 
определенных проблем на ранних этапах проекта навело на мысль, что 
и далее проблемы не будут найдены. И наоборот, если обнаруживается 
масса проблем и проект испытывает трудности, необходимо определить 
возможные пути выхода из кризиса. Под “связью с ходом проекта” и “пу- 
тями выхода из кризиса” не обязательно понимать “выпуск версии в срок 
во что бы то ни стало”. Напротив, я понимаю это как определение разум- 
ного множества компромиссов и решений о равновесии сроков, бюдже- 
та, свойств и качества в рамках широкого контекста технологии, проекта 
и компании. 

Это особенно касается незапланированных обсуждений, например 
внепланового совещания по обсуждению критической ошибки. Вспом- 
ним взрыв космического челнока “Челленджер”. Трагедия этой катастро- 
фы вышла за пределы обсуждения гибели на глазах всего мира семи чело- 
век ясным и холодным утром. Более глубокая трагедия заключалась в том 
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факте, что за день до того, как это случилось, инженеры Могіоп Токо! 
предоставили информацию о случайной связи между понижающейся тем- 
пературой и вероятностью проблем с уплотнительными кольцами руко- 
водителям запуска и официальным лицам МАЗА. Если бы эта информация 
была подана правильно, то почти наверняка запуск был бы отложен. Это 
не означает, что инженеры ошиблись. Инженеры правильно оценивали 
информацию. Но руководители запуска и официальные лица не поняли 
ее смысла. К сожалению, ни одна из сторон не подумала о ликвидации 
этой коммуникационной проблемы. 

В книге “Убиа Ехріапайоп Эдвард Тафт, используя многочисленные 
источники, в том числе презентацию Ричарда Фейнмана комиссии аме- 
риканского конгресса, переработал подачу информации. Хотя я не обла- 
даю обширными знаниями в науках о материалах, графики Тафта очень 
четко объясняют, что может случиться с уплотнительными кольцами при 
холодной погоде. 

В публичной лекции по материалам этой книги, включая обсуждение 
катастрофы с Челленджером, Тафт говорил о трех основных уроках, свя- 
занных с представлением данных. 


1. Покажите причинно-следственную связь. 
2. Покажите все существенные данные. 


3. Покажите руководителям то, что они действительно должны уви- 
деть, чтобы принять решение на основе полученной информации. 


Подводя итоги, Тафт спросил: “Какова задача для размышления, в реше- 
ние которой мы хотим вовлечь человека [который заслушивает отчет?” 

Конечно, катастрофа Челленджера — это тот случай, когда инженеры 
могли более эффективно донести суть проблемы. Однако бывают случаи, 
когда тестировщики перегибают палку и представляют ситуацию в очень 
негативном свете. Рассмотрим следующие варианты представления хода 
тестирования. 

Оба этих варианта описывают один и тот же момент времени в одном 
и том же проекте. Первый вариант —это отчет о ходе тестирования, кото- 
рый связан с целями и задачами проекта и предлагает путь решения про- 
блем. Второй отчет упорно и слишком сильно напирает на отрицатель- 
ные стороны. Это может привести к тому, что отчет и сам докладчик 
будут проигнорированы как сеющие панику и безысходность. Итак, оба 
отчета описывают одну и ту же ситуацию в проекте, но первый отчет свя- 
зан с ходом проекта и, по всей вероятности, окажет влияние на дальней- 
шие действия". 


1 РА 
Анализ катастрофы Челленджера, проведенный Тафтом, с большим перечнем дополни- 


тельных источников для дальнейшего чтения можно найти в “Узи Ехрапайот5’, стр. 38 — 53. 
Три упомянутых урока обобщают текст на первой странице главы 1 “Мастерство графическо- 
го представления информации” в "Т/е Ибиа] Різріау о Оиапавие Ттроттайот”. Публичная лек- 
ция, на которой я присутствовал, состоялась в Остине, штат Техас, 28 января 2002 г. Во время 
написания этой книги расследование разрушения челнока “Челленджер” продолжалось. 


2 Касаясь более широкой темы, как стать влиятельным тестировщиком, рекомендую про- 
читать статью Джоанны Ротман “Тһе Гайиелпіїа! Тезі Мапарег”, которая была впервые опуб- 
ликована в журнале "5о/їшате Тезійпр апі Оиаійу Епріпеєтіпр", Уоїате 2, Іѕѕие 2 (Маг/ Арг 2000) 
и доступна в настоящее время на ууу.5(іскутіпаѕ.сот и ум готап.сопа. 
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рость исправления сибе с начала системного ‘тестирования ' составляет 
у примерно 30: ошибок в неделю, плановая дата о 


рование через три! 


Демонстрация тенденций развития качества и возможных 
результатов 


Объединение проблем хода тестирования и проекта в целом подводит 
нас кследующему признаку качества процесса подготовки отчетов о ходе 
тестирования: там, где имеет смысл, необходимо показывать тенденции 
и возможные результаты. 

Первые результаты тестирования в проектах разработки, сопровож- 
дения, конфигурации и интеграции, вероятно, покажут некоторое теку- 
щее состояние качества. По мере развития проекта качество должно, по 
идее, улучшаться. Состояние качества меняется со временем. По мере 
того как происходят эти изменения, развиваются тенденции. Тенденции, 
если их правильно представить, могут дать информацию не только о том, 
в каком состоянии находится проект, но и куда он идет. Следовательно, 
информация о тенденциях позволяет руководителям прогнозировать, ка- 
ким будет качество в будущем. В каком состоянии проект с точки зрения 
устранения ошибок? Когда система будет готова к поставке? 

В нашем примере инструментальная панель Джамала показывает тен- 
денции, а также оценки того, куда движется проект. Сглаживающаяся 
кривая совокупного числа открытых ошибок демонстрирует стабиль- 
ность или, по крайней мере, неспособность группы тестирования найти 
еще больше ошибок при помощи существующей системы тестов. Кривая 
совокупного числа закрытых ошибок, сходящаяся с кривой открытых 
ошибок, указывает на качество — решение проблем, обнаруженных при 
тестировании. График выполнения тестов показывает выполненные тес- 
товые сценарии (тесты, прошедшие без ошибок, и тесты, завершившиеся 
неудачей) и невыполненные тестовые сценарии. Данный график позво- 
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дяет руководителям увидеть, сколько еще нужно выполнить тестов, како- 
ва доля тестовых сценариев, которые не могут быть выполнены, и соот- 
ношение между успешно и неуспешно завершившимися тестами. 

Представление тех же данных, которое не дополнено динамикой из- 
менения значений и прогнозом развития ситуации, вероятно, будет ли- 
шено элемента предвидения. Помните, что одним из путей, при помощи 
которого тестирование увеличивает стоимость компании, является со- 
провождение проекта своевременной, точной и заслуживающей доверия 
информацией о ходе проекта. Информация о тенденциях и возможных 
результатах имеет существенное значение для сопровождения проекта. 

Конечно, есть такая аудитория, которая интересуется прежде всего со- 
стоянием на текущий момент. Подробные тактические отчеты для разра- 
ботчиков, бизнес- аналитиков, персонала технической и сетевой под: 
держки пользователей должны, вероятно, быть направлены на вопросы, 
требующие немедленного реагирования. Чтобы предоставить эти сведе- 
ния, можно использовать краткое описание тестовых сценариев, ком- 
плектов тестов, дефектов и даже нолные отчеты об ошибках. Краткий от- 
чет о тестовых сценариях может содержать перечень сценариев по 
одному на строку, включая текущий статус, связанные отчеты об ошиб- 
ках, протестированные конфигурации и т.д. Краткий отчет об ошибках 
может показывать ошибки по одной на строку, включая номер, краткое 
описание, дату открытия, серьезность и прочую полезную информацию. 

Существует одно исключение из правила, связанного с необходимо- 
стью показывать тенденции: если вы проводите приемо-сдаточные испы- 
тания единственной версии, для которой не являются проблемами во- 
просы интеграции и конфигурирования. В этом случае наиболее 
подходящим способом отчета о результатах тестирования является, по 
всей вероятности, моментальный снимок: либо система подходит для ис- 
пользования и готова к поставке, либо предложение поставщика не гото- 
во. Оценку нескольких конкурентных продуктов от разных поставщиков, 
из которых делается выбор, также удобно проводить при помощи момен- 
тального снимка текущего состояния. 


Применение подходящих механизмов и документов 


В нашем примере Джамал использовал показ слайдов в качестве стиля по- 
дачи информации и устное пояснение каждого графика и его значения 
в качестве механизма подачи результатов. Слайды содержали графики, 
построенные при помощи программы обработки таблиц. Он также при- 
менял электронную почту для предварительной рассылки таблиц участ- 
никам совещания, чтобы они могли при желании подготовиться к сове- 
щанию. Это один из способов использования механизмов подготовки 
и доведения результатов, причем он не является необычным. 

В моем методе управления проектами тестирования подготовка крат- 
ких отчетов о результатах тестирования начинается с определения вы- 
полненных тестов, сниженных рисков, найденных и исправленных оши- 
бок и взаимосвязей всех этих элементов с запланированными или 
ориентировочными измерениями и оценками завершения. Я организую 
проект тестирования на основе структурированной и измеряемой систе- 
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мы тестов с тщательно спроектированными и разработанными тестами, 
четкой взаимосвязью между рисками качества и тестами и с формализо- 
ванными базами управления дефектами. Из этой системы тестов я извле- 
каю имеющие смысл измерения и суммарные данные. Некоторые тест- 
менеджеры более подробно документируют системы тестов, чем это де- 
лаю я, некоторые комфортней себя чувствуют с меньшим количеством 
документации. Частично связь результатов тестирования и контекста, 
как обсуждалось в главе 1, должна использоваться для повышения эффек- 
тивности работы системы тестов в вашей компании. 

Я также люблю численно измерять результаты тестирования. При 
этом я получаю более глубокое представление, чем только при качествен- 
ном подходе. Количественная оценка ключевых индикаторов лежит в ос- 
нове моего понимания состояния тестирования. Я вижу, что мои клиен- 
ты, коллеги и члены группы тестирования обычно более уверенно себя 
чувствуют, если результаты имеют количественную оценку. Процитирую 
Лорда Кельвина: “Если... вы не можете выразить [то, о чемвы говорите] в 
числах, ваши знания скудны и имеют неудовлетворительноє качество”. 

Работая с количественными оценками результатов тестирования, я счи- 
таю важным для себя выделить из информации значимые данные. Я обыч- 
но получаю поток данных тестирования, который меняется ежедневно. 
Просто вывалить кузов самосвала с данными на людей — это не передача 
информации, это только собьет их с толку. Вот почему процесс, описан- 
ный выше, связывает измерения тестирования с соответствующим контек- 
стом, с целями проекта и с вопросами по поводу этих целей. 

Соображения эффективности получения информации и обмена ею 
также имеют значение. В идеале вы можете обобщить сведения о состоя- 
нии дел с тестированием автоматически и безо всяких усилий при помо- 
щи инструментальной панели и других отчетов о ходе тестирования. По- 
лучатели отчетов должны уметь проникать в легко доступные источники 
данных об ошибках, ходе тестирования, покрытии рисков. (По различ- 
ным причинам юридического характера вы, вероятно, можете закрыть 
доступ к определенным данным о процессе тестирования, особенно, если 
у вас есть ощущение, что они могут быть неверно интерпретированы, 
сбить с толку или даже умышленно указать неверное направление.) 

Подход одного из моих крупных клиентов состоял в размещении инст- 
рументальной панели тестирования в локальной сети компании. Все гра- 
фики автоматически и одновременно обновлялись на регулярной осно- 
ве, на основе извлечения исходных файлов данных из стандартного 
репозитория. Как только процесс был запущен, он сразу показал свою эф- 
фективность, хотя в создание инструментов и процесса было вложено 
всего три человеко-месяца. 


Более подробно о преимуществах различных измерений, связанных с ошибками и тести- 
рованием, можно прочитать в главах 4 и 5 моей книги “Мопоріпр йе Тезійпе Ргосезз, Зесоп4 
Каййоп". Другой взгляд представлен в статье Майка Кона (Міке Сорп) “А Меаѕигеа Везропзе”, 
опубликованной впервые в журнале "о/їшате Тейпе апа Оиаійу Епріпеетіпр", Моите 4, Іѕѕџе 5 
(бер/ Осі 2002) и доступной в настоящее время наумуу.5іскутіпаѕ.сот. Наконец, посмотри- 
те статьи Сема Канера “Сет Капег оп Кефіпкіпо Зоймаге Мегісѕ” на улум.3 Пскутіпаз.соп и 
“Меазигетепе ое Ехтепі ої Теѕііпр” на мугу.Капег.соп. 
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Наконец, позвольте мне отметить, что диаграммы и графики, показан- 
ные в примере, можно подготовить при помощи таблиц Ехсе!. В качестве 
альтернативы вы можете вложить средства в разработку своих собствен- 
ных средств, чтобы создать всеобъемлющий инструмент, как это сделал 
мой клиент. Однако если вы приобрели или рассматриваете вопрос о 
приобретении коммерческого инструмента управления тестированием, 
этот инструмент должен генерировать все необходимые отчеты о ходе 
тестирования. Вероятно, необходимо сконфигурировать инструмент и 
совокупность отчетов. Как только это будет сделано, вы будете тратить 
свои силы только на распечатку подготовленного отчета из базы данных 
или предопределенного графика из программы обработки таблиц. Если 
инструмент не способен генерировать отчеты или делает это неуклюже, 
он не удовлетворяет разумным ожиданиям качества и функциональности 
профессионалов в тестировании. Если можно, откажитесь от такого ин- 
струмента в пользу другого, который умеет делать все необходимое. 


Передача информации в удобной для каждого потребителя 
форме 


До некоторой степени я обобщил понятие аудитории. Каждой группе: ме- 
неджерам, топ-менеджерам, разработчикам и т.д. — нужна своя информа- 
ция. Обобщение полезно при определении точки отсчета для измерений 
и отчетности, но я хочу, чтобы вы исследовали возможность подстройки 
ваших отчетов под отдельное заинтересованное лицо. Вероятно, вы уди- 
витесь, обнаружив новые и полезные способы, при помощи которых вы 
сможете своевременно предоставлять нужную информацию проектной 
группе. 

В качестве примера не из области разработки программного обеспече- 
ния рассмотрим информационные источники, которые вы цените. Точ- 
но ли совпадают ваши интересы со стереотипами, которые существуют 
относительно вашего пола, возраста, этнической принадлежности, поли- 
тических убеждений и т.п.? Поскольку я - мужчина, проживающий в юж- 
ной части Соединенных Штатов (Техасе), согласно стереотипу, я должен 
читать спортивный раздел газет. Но я этого не делаю. Я никогда не смот- 
рю соревнования профессиональных спортсменов по телевизору. Одна- 
ко покажите мне статью о том, как приготовить индийскую или китай- 
скую пищу, и я жадно буду ее читать. 

Я работал с менеджерами по маркетингу, которым нравилось торчать 
в тестовой лаборатории, наблюдая за отказами тестовых сценариев. Не- 
которые менеджеры разработки любили просматривать тестовые сцена- 
рии, чтобы убедиться, что модульное тестирование является дополнени- 
ем к остальным видам тестирования. Некоторые менеджеры проектов 
ожидали от меня самого свежего отчета о состоянии тестирования даже в 
ситуациях, которые продолжали развиваться. Другие менеджеры проек- 
тов предпочитали получать тщательно проанализированные результаты 
тестирования. 

Вновь отмечу, что основной момент — это передача информации. По- 
этому я нахожусь в поиске путей, позволяющих настроить доставку сооб- 
щений на волну слушателей. Я готовлю специальные сообщения о ходе 
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работ, провожу неформальные обсуждения с глазу на глаз и даже посе- 
щаю совещания о состоянии дел других менеджеров с избранными отче- 
тами. 

Когда я настраиваю сообщение на волну слушателя, то мысленно став- 
лю себя на его позицию. Что ценит слушатель? Как тестирование служит 
его интересам? Что я могу сообщить из того, что он хочет узнать для при- 
нятия решения о дальнейших действиях? Что и как я должен рассказать 
для того, чтобы в голове у слушателя в соответствии с его точкой зрения 
выстроилась четкая картина о ходе тестирования? 

Наконец, хотелось бы отметить, что поскольку тестирование часто 
выступает в качестве услуги компании, важно, чтобы любое взаимодейст- 
вие группы тестирования и заинтересованных в тестировании лиц укреп- 
ляло положительное впечатление от вклада группы тестирования в про- 
ект. Это особо касается отчетности о результатах тестирования, которые 
часто являются неприятными новостями. 

Настройка передачи информации на конкретного слушателя демонст- 
рирует уважение кэтому человеку, что способствует положительному вос- 
приятию работы группы тестирования. Те из нас, кто имеет опыт техни- 
ческой карьеры, должны продумать, как общаться с людьми, далекими от 
глубокого понимания высоких технологий. Например, можно ли инфор- 
мировать о ходе тестирования или об отдельных проблемах в свете целей 
проекта, а не в терминах дампов памяти, неинициализированных указа- 
телей, неподдерживаемых элементов управления окнами и так далее? 
Тестировщикам полезно изучать технологии создания систем. Однако 
необходимо иметь в виду, что многие технические словечки, сокраще- 
ния, понятия и жаргон неприемлемы для непосредственных исполните- 
лей и менеджеров, которые не являются техническими экспертами. 
Использование неприемлемых слов не производит впечатления на ауди- 
торию, а только запутывает ее. 

Я вовсе не хочу сказать, что представление результатов должно быть 
покровительственным. Если люди хотят понять сложный технический 
вопрос, чтобы разобраться в определенной части хода тестирования, 
фраза “это сложно, вы вряд ли поймете” будет оскорбительной для ауди- 
тории и опасной для проекта. Такое сообщение также унизит вас как про- 
фессионала, поскольку вы недооцениваете свои коммуникативные спо- 
собности. Теперь вы, вероятно, согласитесь со мной, что эффективная 
передача информации — важный навык тестировщика-профессионала, 
и прямо сейчас отведете время на обучение тому, как делать это лучше. 


Решение проблем 


Процесс передачи информации сложен по своей природе. Передача инфор- 
мации о ходе тестирования особенно затруднена по целому ряду причин. 


Подготовка презентации 


Формальные совещания и презентации, в отличие от электронной почты 
и других неинтерактивных способов отчетности о результатах тестирова- 
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ния, вероятно, наиболее напряженные мероприятия в плане информиро- 
вания о результатах тестирования. Однако такие форумы являются наибо- 
лее эффективными. Отправка отчета в корпоративную сеть не означает, 
что все его прочтут. Отправка по электронной почте файла в формате 
Ехсе], полного диаграмм и графиков, объемом в 2 мегабайта, не означает, 
что каждый откроет прикрепленный файл. При любом неинтерактивном 
способе отчетности о ходе тестирования ваши возможности в получении 
обратной связи сильно ограничены. Поэтому во многих проектах интерак: 
тивное представление результатов тестирования, либо на телеконферен- 
циях, либо лично, необходимо делать время от времени. 

Новичкам в ритуалах управления, в том числе в проведении совеща- 
ний и презентаций, полезно прочитать книгу Патрисии Энсворт “Те 
Ассійепіаї Реоуєсі Мапарет". И новичкам, и людям с опытом я рекомендую 
книгу Эдварда Тафта“ Уізиа! Ехріапайопу", в которой обсуждаются правила 
подготовки презентаций. Хотелось бы в дополнение к их идеям, относя- 
щимся к базовым навыкам презентации результатов, дать следующие со- 
веты, касающиеся прежде всего тесг-менеджеров. 


ш На совещания, посвященные ходу работ, приходите, подготовив 
слайды и другие сопроводительные документы. Чемвыше статус ау- 
дитории, тем меньше слайдов я приношу с собой, но тем более тща- 
тельно готовлю каждый слайд. Чем хуже новости, тем больше со- 
путствующих данных я беру с собой и тем тщательнее я готовлюсь. 
Однако я стараюсь показать плохие новости на небольшом множе- 
стве понятных графиков, что концентрирует внимание аудитории 
на наиболее важной информации. В основном примере Джамал по- 
стоянно фиксировал внимание на том, что сообщают графики о ка- 
честве системы, предназначенной для тестирования, а не на отвле- 
кающих и непродуктивных вопросах, которые могли бы возникать, 
например: хорошо ли идет тестирование? 


в Демонстрируйте вашей аудитории слайды, графики и отчеты, ука- 
зывая на хорошие и плохие новости. То, что является очевидным 
для специалистов- тестировщиков, привыкшим читать такие гра- 
фики, ничего не значит для коллег- менеджеров и высшего руково- 
дства. Что еще хуже, они могут неправильно интерпретировать 
вашу информацию. В нашем примере Джамал тщательно разъясня- 
ет смысл графиков, как в общем (т.е. вопросы, на которые отвечает 
каждый график), так и в частностях (т.е. каково значение информа- 
ции, представленной на каждом из графиков, для проекта). 


и Принимайте предложения и вопросы с улыбкой, старайтесь не про- 
тестовать. Тестировщики (как и разработчики, инженеры сборки и 
другие непосредственные исполнители} получают кучу предложений 
в ходе обсуждения состояния тестирования. Я пытаюсь выслушивать, 
воспринимать и выражаю готовность к обсуждению, но я никогда не 
спешу изменять мои тщательно выстроенные план тестирования, сис- 
тему тестов и процессы тестирования в ответ на импровизированное 
предложение или отклик на совещании о ходе проекта. 


Эти идеи могут оказать помощь в начале работы. Тем не менее, я пыта- 
юсь добиться того, чтобы мои глаза и уши, сердце и ум были открыты, ко- 
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гда я работаю над представлением результатов тестирования. Совместно 
с моими коллегами я усиливаю и осваиваю стили, которые зарекомендо- 
вали себя, и расстаюсь с неудачными стилями. Это особенно актуально в 
свете следующей проблемы. 


Носитель плохих новостей 


Легко сообщать людям хорошие новости, которые четко отражают их дос- 
тижения и не требуют действий с их стороны. Например: “Мы выполнили 
все тесты и не нашли ошибок, поэтому сегодня мы завершаем системное 
тестирование согласно графику”. Труднее передавать плохие новости, осо- 
бенно когда из них следует, что тот или иной работник совершил ошибку и 
должен предпринять действия для устранения последствий. 

Реакция на плохие новости — это из области психологии, но не являет- 
ся чем- то неизвестным в сфере программирования. На первой странице 
главы “Назревание катастрофы” в книге "Мифический человеко-месяц" Фред 
Брукс поместил изображение скульптуры Геракла, убивающего гонца Ли- 
хаса за то, что он принес плохие вести. Бедный Лихас. Время от времени 
многие тестировщики подвергаются аналогичному остракизму. 

Помимо иррациональных причин такой реакции на плохие вести и их 
носителя, часто существуют вполне разумные причины. Прежде чем об- 
винять руководителей Моцоп Токо! и официальных лиц МАЅА в катаст- 
рофе Челленджера, подумайте вот о чем. К руководителям и официаль- 
ным лицам обратились с предложением отсрочить миссию, в которой 
был политически заинтересован лично президент США Рональд Рейган. 
В космическом полете должны были впервые участвовать учитель и жен- 
щина. И с точки зрения холодной войны, и с точки зрения равенства по- 
лов этот полет имел большое символическое значение в середине 80-х го- 
дов. Откладывание полета было бы не только непопулярным решением, 
это было бы также затратным решением. Наконец, представьте позицию 
менеджеров и руководителей Могіоп ТШоКо], к которым обращались спе- 
циалисты с просьбой занять жесткую позицию по отношению к всесиль- 
ному и выгодному заказчику. Единственное честное решение, которое 
могли бы сделать менеджеры и официальные лица, так это попросить ин- 
женеров доказать их опасения. Аналогично, когда мы предлагаем отло- 
жить выпуск версии или потратить еще денег натестирование, едвали ра- 
зумно ждать от руководства похвалы. 

Врядли можно полностью овладеть искусством подачи плохих вестей. 
Если тестировщикам и тест-менеджерам удается эффективно подавать 
плохие новости разумным людям, это следует оценивать как признак вы- 
сокой квалификации. Чтобы добиться цели в таких ситуациях, требуются 
мастерство в деталях, подходящий стиль и манера поведения при сообще- 
нии новостей. Успех зависит от менеджера и от группы управления, но, 
по моему мнению, нелишними будут следующие советы. 


ш Сохраняйте спокойствие и терпение. Логическое представление 
лучше передает факты, чем эмоциональное. Иногда приходится по- 
яснять какие-то детали разными способами, чтобы всем было по- 
нятно. Я рассматриваю передачу информации как часть моей рабо- 
ты даже в проблемной аудитории и в сложных обстоятельствах. 
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и Будьте тактичны. Я имею доступ к информации, которая может 
смутить слушателей, унизить коллег, если подать ее необдуманно. 
Я тщательно выбираю данные, относящиеся к неудачно завершив- 
шимся тестовым сценариям и отдельным отчетам об ошибках, по- 
скольку их могут посчитать поводом для резкой критики или обви- 
нения. Бездумно подготовленный отчет может быть использован в 
качестве оружия против других, даже если я не предполагал этого. 


и Не будьте дон Кихотом, одиноким рыцарем качества", Не считайте 
себя ответственным за качество системы и не соглашайтесь прини- 
мать на себя такую ответственность, если это не входит в ваши 
должностные обязанности. К моим обязанностям обычно относит- 
ся работа эксперта по управлению рисками качества системы. 
В контексте подготовки отчетов о результатах тестирования это оз- 
начает наличие достаточной квалификации для подготовки отче- 
тов по отдельным рискам, отдельным тестам, отдельным ошибкам, 
а также для определения тенденций и последствий результатов тес- 
тирования. Я прилагаю все усилия к тому, чтобы результаты гово- 
рили сами за себя, чтобы дать возможность руководству выбрать те 
ошибки, которые нужно исправить, а программистам внести эти 
исправления. 


й Не радуйтесь ошибкам. Талантливый тест-менеджер Рейнольдс 
Макнари (Кеупо!аѕ МасМагу) однажды сказал мне: “Будь оптими- 
стом снаружи и пессимистом внутри”. Как тест-менеджер, я хочу, 
чтобы мои тестировщики выполняли тесты, находили ошибки 
и снижали риски в порядке приоритетов. Я удовлетворен профес- 
сионализмом моей группы, когда они работают именно так. Однако 
непрошедшие тесты, ошибки с высоким приоритетом и опасные 
инциденты, связанные с рисками, являются плохими вестями для 
проекта. Я считаю, что не следует принимать уж слишком мрачный 
вид, когда докладываешь о проблемах, особенно в том случае, когда 
просто говоришь кому-нибудь: “Я рассказал тебе, как обстоят дела”. 


Здесь основной вопрос -- стремление деперсонализировать презента- 
цию плохих новостей, чтобы четко отделить сообщение о плохих ново- 
стях, неудачу в проекте от носителя новостей, профессионала, который 
хочет сделать своевременное предупреждение. 

Для сравнения представьте врача, который должен сообщить пациен- 
ту, что он страдает от опасного, возможно, смертельного заболевания. 
Врач, конечно, помогает больному, сообщая ему о болезни, поскольку 
больной может сразу же заняться лечением. Вероятно, что врач заинтере- 
сован в лечении пациента и в совершенствовании своих навыков в борь- 
бе с недугом. Более того, может статься, что врач в течение нескольких 
лет предупреждал пациента, чтобы он изменил какие-то привычки, кото- 
рые привели его к болезни. Однако какими бы ни были обстоятельства, 


1 Вкниге Мигеля Сервантеса “Дон Кихот” главный герой страдает от повреждения рассуд- 


ка, в результате чего он воображает себя странствующим рыцарем. Он защищает честь де- 
вушки, которая оказывается проституткой, и бьется в поединке с ветряной мельницей, ко- 
торая представляется ему опасным великаном. Тестировщики, которым кажется, что они 
одинокие рыцари качества, часто выглядят такими дон Кихотами. 
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исключительно неразумно в такой ситуации говорить: “Я предупреждал 
пять лет назад, чтобы вы бросили курить”, предлагать волшебное зелье, 
преувеличивать возможности в умении лечить такие заболевания или ве- 
роятность выздоровления, жестоко обращаться с пациентом в то время, 
когда он испытывает страдания, или поскорее вытолкнуть его за дверь, 
чтобы принять следующего. 

Для носителя плохих новостей самые большие проблемы возникают, 
когда необходимо выступать на совещании, на котором принимается ре- 
шение о выпуске или поставке продукта. Ставки здесь как никогда высо- 
ки, и ощущается острая потребность в позитивной информации. Однако 
если вести нерадостные, голос тестировщика обычно одинок, когда он 
рассказывает о рисках, относящихся к качеству системы, в то время как 
другие говорят о давлении сроков, бюджета, свойств, что делает немедлен- 
ную поставку системы абсолютно критической. 

Некоторые тест-менеджеры очень хотят иметь право на остановку вы- 
пуска системы. Наверное, они думают, что играют в игру с нулевой сум- 
мой, в игру, в которой качество важнее всех остальных соображений. Но 
может ли сотрудник или часть сотрудников, занятых в проекте, достичь 
успеха, если весь проект провалился? Что касается меня, то в игре, в кото- 
рую мы играем, сумма может существенно превысить нуль или, наоборот, 
стать существенно меньше нуля в зависимости от того, принимает ли 
группа проекта, в особенности группа управления проектом разумное ре- 
шение по поводу выпуска или поставки системы. 

Поэтому я не выступаю в роли полицейского, который следит за каче- 
ством. На самом деле я неоднократно сталкивался со случаями, когда мои 
клиенты хотели возложить на меня эти обязанности. Но я хочу занимать 
свое место за столом, я хочу быть доверенным и влиятельным советником 
по вопросу качества. Я абсолютно счастлив, находясь на совещании, по- 
священном принятию решения о выпуске системы, когда я сосредоточен 
на представлении четкой, хорошо поданной оценки качества и готовно- 
сти системы. (Как отмечалось в главе 7, я часто применяю критерии 
завершения заключительной фазы тестирования, например критерии за- 
вершения системного тестирования, в качестве измерительного инстру- 
мента.) Я даже осмеливаюсь высказать мнение по поводу текущего со- 
стояния рисков качества в сравнении с рисками бюджета, сроков 
и свойств. Однако в случае, подобном рассматриваемому нами примеру, 
часто тест-менеджер или тестировщик не располагает всей информаци- 
ей, необходимой для принятия взвешенного решения по поводу выпуска 
продукта. В то же время, своевременно предоставляя полезную информа- 
цию о качестве, которой можно доверять, тест-менеджер остается неза- 
менимым поставщиком ключевой части информации, которая необходи- 
ма группе управления проектом для принятия разумного и взвешенного 
решения. Вот в этой роли я и стремлюсь выступать. 

Эти советы предназначены для передачи плохих новостей разумным 
людям. А что делать с неразумными? Есть такие, кто поступает неразумно 


1 б, а ОСА 
Для дополнительных размышлений на эту тему ознакомьтесь со статьей “Каеазе Стігегіа" 


Джоанны Ротман, впервые опубликованной в "Зо/шате Тейт апі Оиайу Епріпеєтіпр", Моїдте 4, 
Іѕѕце 2 (Маг/Арг 2002) и доступной в настоящее время на у\м\у.зисКупипз.сот и 
ми тоштап.сот. 
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без всякого оправдания часто и в ущерб себе, и в ущерб коллегам. Некото- 
рые используют неблагоразумие в качестве стиля управления, особенно 
это касается применения тактики оказания давления. 

Некоторые люди, считающие положение с тестированием неприят- 
ным, пытаются заглушать или затемнять значение плохих новостей и за- 
одно запугивать и показывать несостоятельность их носителя. В среде, 
где люди прибегают к этой тактике, я пытаюсь отстаивать свою позицию, 
сохраняя благоразумие, спокойствие и последовательность. (Если меня 
никто не слушает или не проявляет благоразумия, то, как показывает мой 
опыт, лучше просто помолчать.) На тех совещаниях, где используется по- 
добная тактика, я обычно разговариваю с теми, кто слушает, я строю от- 
ношения с восприимчивыми коллегами, пытаясь направить информа- 
цию в обход тех, кто устраивает обструкцию, сбивает с толку или 
переходит к персональным обвинениям. 

В “Искусстве войны” Суньцзы предупреждает читателя, что мудрый 
охотник не нападает на тигра в его норе, а мудрый полководец не ввязыва- 
ется в сражение, чувствуя слабость своего положения. Я предлагаю это 
сравнение не для того, чтобы рекомендовать воинственное поведение со 
своими коллегами-менеджерами, а для того, чтобы стимулировать к поис- 
ку естественных союзников группы тестирования, которые знают статус 
тестовых сценариев и ход устранения ошибок и принимают участие 
в этой работе. 

Наконец, нужно отметить, что некоторые люди неразумно восприни- 
мают отчеты о результатах тестирования по абсолютно понятным причи- 
нам. Возможно, они себя так ведут из-за нереалистичных ожиданий от 
проекта, сформировавшихся и укрепившихсяу них. Для того чтобы сооб- 
щения о плохих новостях были результативными, все должны быть гото- 
вы кэтому с самого начала проекта, когда мы определяем контекст проек- 
та, оцениваем риски качества, делаем оценку затрат в проекте и 
проводим планирование. Вероятно, люди ведут себя неблагоразумно по- 
тому, что они не считают группу тестирования надежным источником по- 
лезной и своевременной информации. Трудно наладить и укрепить дове- 
рие постфактум, но мы должны сохранять внимание в ходе всего проекта. 
для того, чтобы управлять как качеством работы группы тестирования, 
так и впечатлением от этой работы“. 


1 
о работ е с патологически неразумными людьми н с теми, кто поступает неразумно в так- 


тических целях, рассказывается в книге Эда Йордона “Путь камикадзе”. Неплохое обсужде- 
ние проблем, связанных с дополнительным давлением на работу команды и производитель- 
ность персонала, можно найти в книге Тома де Марко и Тима Листера “Реоремаге”. 


Помимо управления, имеют место также обсуждения с глазу на глаз, которые проходят 
между тестировщиками и программистами и другими непосредственными исполнителями. 
В статье Карен Джонсон (Кагеп Јоһпѕоп) “Хейуеная Опмеісоте Мем5з го Оеуеіоретгз”, впер- 
вые опубликованной в журнале "бо/їшате Тезійпр апа Оиаійу Епріпеегіто", Уолте 4, Іѕѕие 5 
(5ер/ Осі 2002) и доступной в настоящее время на мүғм.ѕіскутіпіѕ.сот, приводятся некото- 
рые полезные идеи о взаимодействии на этом уровне. 
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Постоянно меняющаяся сложная история 


Иногда мы можем описать новости как “хорошие” для тестирования. 
Иногда мы считаем их “плохими”. Обычно нрисутствует комбинация 
и тех, и других. Но одно прилагательное мы можем присоединить навсе- 
гда к новостям о тестировании — “изменяющиеся”. 

В ходе выполнения тестов постоянно обнаруживаются новые пробле- 
мы. Если я потрачу пару часов на подготовку слайдов для совещания по со- 
стоянию дел в проекте, то к концу совещания мой отчет будет несвежим. 
С другой стороны, если я быстро составлю презентацию, то, вероятно, 
приду на совещание с недостаточно хорошо подготовленным отображе- 
нием состояния дел в тестировании. Поэтому приходится идти на ком- 
промисс между точностью и своевременностью, между самыми свежими 
данными и ясностью анализа результатов. Как и проблема интерпрета- 
ции результатов тестирования (см. главу 13), правильный баланс в приня- 
тии компромисса зависит от контекста. В данном случае контекст опреде- 
ляется информационными потребностями аудитории. 

Интересует ли аудиторию точный подсчет тестовых сценариев, число 
прошедших и непрошедших тестов и т.п.? Если да, то я должен в течение 
некоторого времени проверить, что все мои отчеты согласованы, но это 
означает, что мои результаты устареют к моменту, когда люди их получат. 
Хочет ли аудитория получить самые свежие результаты, самые актуаль- 
ные новости, даже если детали неясны? Если это так, я должен сделать 
процесс подготовки отчетов о результатах тестирования быстрым, не- 
смотря на некоторую их неточность во времени. 

Чтобы правильно сбалансировать актуальность и точность отчетов о 
результатах тестирования, я привлекаю к обсуждению моих коллег- 
менеджеров и других заинтересованных лиц. Я показываю, сколько вре- 
мени необходимо для достижения определенного уровня точности и со- 
гласованности в отчетах и что написание отчетов отрывает меня от про- 
цесса тестирования. Таким образом мне обычно удается получить 
рекомендации для принятия верного решения. Слово “решения”, вероят- 
но, наиболее подходящее. Желания потребителей моих отчетов могут 
слегка отличаться. Я уже говорил, чтобы умело передавать информацию, 
необходимо нацеливать каждое сообщение на конкретного слушателя. 
Хотя форма подачи отчетов о результатах тестирования для группы слу- 
шателей адресуется некоторому среднему слушателю, я могу подготовить 
специально адаптированную информацию для различных заинтересо- 
ванных лиц. Адаптированные отчеты могут удовлетворить предпочтения 
отдельных потребителей в отношении сочетания своевременности и 
точности информации. . 

Даже при неограниченном количестве времени на подготовку отчетов 
невозможно все предусмотреть. Я не могу знать все. Например, я не могу 
по памяти подробно рассказать о каждом из 300—400 незакрытых отчетов 
об ошибках. Точно так же я не могу ответить на конкретные вопросы от- 
носительно определенного условия, спрятанного в одном из 200—300 тес- 
товых сценариев. Когда мне задают такие вопросы, я улыбаюсь и говорю 
что-нибудь вроде: “Да, ты победил в игре “Поймай тупицу”! Я не знаю от- 
вета на этот вопрос, но я изучу проблему сразу после совещания, если ты 
не против”. 
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Поскольку я обычно хорошо подготовлен, откровенное признание не- 
дочета вместе с готовностью немедленно предоставить информацию вся- 
кий раз одерживает победу. Однако я должен быть готов к подробному об- 
суждению серьезных ошибок, наиболее ‘серьезных сбоев тестовых 
сценариев и наиболее опасных рисков. Проницательные менеджеры зас- 
то задают мне детальные вопросы об обстоятельствах, вызвавших поте- 
рю данных или функциональности, появление узких мест производитель- 
ности или неисправность коронного свойства. 


Сочетание переживания за качество с бесстрастным 
представлением результатов 


Как тестировщики-профессионалы, мы обычно концентрируем усилия 
на проблемах и рисках. Это верно, поскольку часто роль группы тестиро- 
вания — помочь в управлении рисками системы качества. Однако стрем- 
ление к этому может превратиться в дон-кихотовское поведение, о чем я 
писал раньше. Как сохранить высокое стремление к качеству и избежать 
его превращения в препятствие для проекта? 

Прежде всего необходимо осознать, что поскольку мы понимаем, что 
отчеты об ошибках и информация о неудачно завершившихся тестовых 
сценариях ставят новые задачи перед программистами, мы, тестировщи- 
ки, имеем естественное человеческое желание знать, как группа управле- 
ния проектом оценивает ход тестирования. Во всяком случае, мы хотим, 
чтобы нашу работу ценили. 

Однако важно понимать, что тестирование не происходит само по 
себе. Компании содержат группы тестирования не для удовлетворения 
праздного интеллектуального любопытства, а для получения специаль- 
ных услуг по управлению рисками качества в контексте конкретного про- 
екта. Эти услуги помогают группе управления проектом уравновесить че- 
тыре элемента — качество, свойства, сроки и бюджет, — чтобы принимать 
решение на основе полной информации. 


Внедрение усовершенствований 


Сучетом того, что все тестировщики должны находить точные пути пере- 
дачи информации о результатах тестирования, каким образом можно 
внедрить усовершенствования? В широком смысле я могу предложить 
следующие отправные точки. 


1. Начните с вопросов заинтересованным лицам относительно того, 
что они думают о текущих информационных продуктах и услугах, 
которые они получают от группы тестирования. Этот шаг сам по 
себе увеличит доверие к группе тестирования, поскольку он демон- 
стрирует, что вы заботитесь о пользе и своевременности своих ре- 
зультатов. 


2. Будьте готовы показать примеры. Вы можете дать легкое и нечет- 
кое описание того, что можно получить из предлагаемых графиков 
или отчетов, но только примеры, особенно моделирующие реаль- 
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ные ситуации, дают людям возможность почувствовать, какую ин- 
формацию они будут получать. Кроме того, вы сможете изучить их 
реакцию на нее. 


$. Делайте шаги разумного размера. Реализация полностью автомати- 
зированной и интегрированной инструментальной панели может 
быть серьезным шагом. Зачем совершать такие значительные дей- 
ствия, если вы не полностью уверены в том, что именно это вам 
нужно? Может быть, проведение в течение некоторого времени 
анализа вручную с использованием средств обработки таблиц, базы 
данных, программ для построения графиков и т.п. поможет точно 
выразить все, что требуется. 


4. Сохраняйте низкий уровень накладных расходов. Время, которое 
группа тестирования тратит на анализ данных тестирования, по- 
строение графиков, обновление интранет-сайтов и т.д. — это вре- 
мя, в течение которого группа тестирования не проводит оценки 
качества системы, предназначенной для тестирования, и не занята 
работой, направленной на повышение качества этой оценки. Пре- 
доставляйте только ту информацию, в которой нуждаются люди, 
и ни графиком больше. 


5. Работая над улучшением процесса, непрерывно отслеживайте эф- 
фективность процессов подготовки отчетов о тестировании и вос- 
приятие эффективности этой работы. Информационные потреб- 
ности людей и их восприятие работы группы тестирования могут 
быстро меняться, профессионалы-тестировщики должны быть го- 
товы ответить на эти изменения. 


Обсудив подготовку отчетов о результатах тестирования, достигли ли 
мы последнего этапа в процессе тестирования? Во всяком случае, мы про- 
шли весь путь от определения контекста тестирования до формирования 
оценки качества и передачи информации об этой оценке группе проекта. 
И это все, за что нам платят, не так ли? 

В некоторых проектах это так, но в большинстве проектов, в которых 
я работал, был еще один фактор, заслуживающий пристального внима- 
ния, — изменения. Определение проекта включает в себя цели свойств, 
сроков, бюджета и качества системы. Это определение часто меняется по 
мере выполнения проекта. Изменения иногда указывают на проблемы 
в выработке четких требований, архитектуры и планирования работ, но 
они могут также обуславливаться тем, что мы учимся на протяжении про- 
екта. В следующей главе будет показано, как несовершенная подготовка 
и обучение оказывают влияние на изменение проекта и как эти измене- 
ния сказываются на тестировании. 


ГЛАВА 16 


Увеличение возможностей 
для обучения: управление 
изменениями и их влиянием 
на тестирование 


В последних двух главах рассматривался способ, при помощи которо- 
го основные достижения тестирования передаются проектной груп- 
пе. Отчеты об ошибках дают проектной группе вещественные основания 
для улучшения качества системы или для того, чтобы предпринять соот- 
ветствующие шаги по снижению влияния известных ошибок, когда те по- 
падают в эксплуатационную версию. Отчеты о результатах тестирования 
показывают руководству, что некоторые риски, вероятно, ниже, чем 
ожидалось (т.е. некоторые тесты завершились успешно), и предоставля- 
ют менеджерам полезную информацию о проекте в целом, что позволяет 
им вести проект к успеху. 

Эта глава о том, как тестировщики продолжают вносить вклад в совер- 
шенствование проекта, по мере того как проект развивается и изменяет- 
ся . В большинстве проектов мы не собираемся поставлять ту систему, ко- 
торая была показана тестировщикам на первом тестовом цикле. Мы наде- 
емся, что в результате выполнения тестов качество будет улучшаться. Дав- 
ление сроков и бюджета может повлиять на изменение запланированного 
множества свойств системы или запланированного объема тестирования. 
Может оказаться, что некоторые свойства реализовать сложнее, чем ожи- 
далось вначале, в результате эти свойства будут удалены из системы. Есте- 
ственно, мы собираемся многое узнать о системе во время выполнения тес- 


1 М А 
Фрагменты этой главы были ранее опубликованы в виде статьи “Тез Ве]сазе Ргосеѕѕеѕ” в 


журнале “/оита1 о/Зойшате Тент Ртојеѕѕіота?, Уоїате 1, Іѕѕџе 2. В статье использовалось боль- 
шое количество цитат моих коллег-тестировщиков. Хотя яудалил цитаты для того, чтобы не 
нарушать общий стиль книги, идеи, изложенные в них, остались. Я бы хотел поблагодарить 
за неоценимый вклад: Рэндала Беккера, Росса Колларда, Гэри Даусона, Харви Дойча, Тима 
Дайеса, Дэнни Фота, Пеги Фоутс, Дарси Мартина и Барбару Руф. 
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тов, получить информацию, которая поможет понять, что нужно делать 
дальше. И, конечно, слишком оптимистичные сроки и бюджеты, нереали- 
стичные ожидания, связанные с тестированием, ошибочная вера в непро- 
веренные технологии часто рушатся в ходе выполнения тестов, что приво- 
дит к довольно драматичному пересмотру оценок проекта. 

Эволюция и изменения происходили практически во всех проектах, в ко- 
торых я принималучастие. С учетом этого обстоятельства проекты тестиро- 
вания должны развиваться и изменяться в качестве ответных мер на получе- 
ние информации об изменениях проекта. Изменения могут охватывать все 
стороны проекта тестирования, включая оценку рисков, бюджеты, графи- 
ки, планы, персонал, систему тестов, тестовые версии, выполнение тестов, 
отчеты об ошибках и результатах тестирования. Короче говоря, тестиров- 
щики должны быть готовы к тому, чтобы перестроить весь процесс тестиро- 
вания и каждый входящий в него ключевой процесс в ответ на изменения в 
проекте. Тестировщики должны соответствовать задачам проекта в целом 
за счет готовности, желания и способности вносить изменения . 


Процесс управления изменениями 


Процесс 12 — это простой обобщенный процесс управления изменения- 
ми. Возможно, вы заметили, что я рассматриваю процесс разбора ошибок 
в качестве элемента процесса управления изменениями. Иногда они раз- 
делены, так что позвольте пояснить, почему я их объединяю. 

В большинстве случаев изменение есть изменение. Источник запроса на 
изменение (отчет об ошибке, подготовленный группой тестирования, или 
запрос на усовершенствование от группы маркетинга) не влияет на то, нуж- 
дается ли система в изменении в ответ на запрос. Источник запроса на изме- 
нение может повлиять на приоритет запроса на изменение. При разработке 
заказных систем запрос на изменение может инициировать увеличение 
стоимости системы для клиента, тогда как исправление ошибки может на 
это не повлиять. Однако для продуктов для массового рынка мы либо удовле- 
творяем потребности пользователей, либо нет. На рынке коммерческих 
продуктов есть такие ситуации, когда имеет смысл отложить до следующей 
версии исправление ошибок, которые со всей определенностью относятся 
к нарушениям установленных и утвержденных требований. Возможны так- 
же случаи, когда имеет смысл не откладывать запрос на усовершенствова- 
ние, который явно находится за рамками тех же самых требований”. 


Эта глава в первую очередь ориентирована на процесс тестирования проекта разработ- 
ки, сопровождения или интеграции, для которого определение успешной передачи систе- 
мы может со временем меняться. Если тестирование проводится для принятия бинарного 
решения — принять или отвергнуть систему, изменения в этом случае менее вероятны, воз- 
можно, лишь в контексте измененного контракта. Аналогично, если тестирование является 
частью оценки конкурирующих систем или компонентов при принятии решения о выборе 
одного из них для поставки в компанию, в этом случае критерии выбора обычно определя- 
ются заранее. 


9 А А У 

Сем Канер, Джеймс Бах и Брет Петтикорд отмечают в "1. е550п5 Геатей т Ѕоўїшоте Тезііпр”: 
“Рассматривайте проект как непрерывное структурированное обсуждение того, что разум- 
но делать дальше” и “Всегда есть изменения на поздних этапах проекта”. 
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Независимо от того, объединяете вы разбор ошибок и управление из- 
менениями в один процесс или используете два отдельных процесса, 
риск изменений обычно возрастает по меретого, как развивается проект. 
Чем меньше остается времени, тем меньше пространства для маневра. 
Поэтому чем ближе мы находимся к плановому окончанию проекта, тем 
меньше изменений мы можем реализовать, не подвергая риску сущест- 
вующие свойства, бюджет, сроки и, возможно, качество. Следовательно, 
в конце проекта этот процесс становится более критическим. 


Процесс 12. Процесс управления изменениями 


№ этапа Этап Выполнено? 
1. Соберите запрашиваемые изменения и исправления ошибок, | 
предлагаемые для включения в текущую, будущую или в ава- 
рийную версию системы. 
2. Обсудите предлагаемые запросы в ходе регулярного или экс- О 


тренного совещания группы управления изменениями, при 
помощи электронной почты или на телеконференции. 


ЗА Оцените связанные с запросами получаемые преимущества в О 
свойствах, бюджете, сроках и качестве, затраты, проблемы и 
риски реализации, тестирования и выпуска версии. При необ- 
ходимости отложите рассмотрение до очередного совещания 
и получите дополнительную проясняющую информацию. 


2.В Присвойте приоритеты каждому отчету об ошибке или от- О 
вергните его. 

2.С Идентифицируйте передаваемые материалы реализации, тес- О 
тирования и интеграции версии; оцените даты завершения 
для каждого запроса. 

3. Спланируйте, реализуйте, протестируйте и интегрируйте из- п 


менение или исправлениє ошибки, отмечая новые затраты, 
преимущества, проблемы и риски. 


4. Представьте результаты реализации, тестирования и интегра- О 
ции версии и передаваемые материалы для окончательного 
утверждения. 

4.А Оцените предстоящие затраты, преимущества, проблемы и О 
риски, относящиеся к свойствам, бюджету, срокам и качеству. 

4.В Сравните преимущества добавления изменения с затратами, 2 
проблемами и рисками. 

4.С Примите окончательное решение: одобрить или отвергнуть п 
изменение в соответствующей версии. 

5. Если внесение изменения утверждено, включите новые или п 


измененные компоненты системы, проектную документацию 
и другие передаваемые материалы в систему управления кон- 


фигурацией. 


и наоборот, чем раньше мы начинаем изменения, тем меньше риск ка- 
ждого изменения. Иначе говоря, чем раньше мы начинаем изменения, 
тем в большей степени один или несколько элементов проекта (свойства, 
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бюджет, сроки и качество) могут быть предметом обсуждения для после- 
дующего изменения. С одной стороны, если требования не зафиксирова- 
ны, является ли требование, которое возникло сегодня и о котором мы не 
слышали вчера, изменением в настоящем смысле этого слова? С другой сто- 
роны, если большинство свойств были реализованы с применением опре- 
деленной архитектуры системы, предложение перейти к новому дизайну, 
вероятно, будет иметь далеко идущие последствия, по крайней мере, для 
графика и бюджета и, весьма вероятно, для свойств и качества. 

Поэтому грамотный процесс управления изменениями зависит от вре- 
мени проекта. Если процесс управления изменениями начинается в пер- 
вый день, вероятно, это приведет к ненужным накладным расходам. Если 
процесс не начать прежде, чем проект выйдет из-под контроля, может 
оказаться слишком поздно. Группа управления проектом должна принять 
решение о том, когда начинать управление изменениями и насколько 
формально и осмотрительно делать это со временем. Ключевым для про- 
екта является грамотный выбор уровня управления изменениями в нуж- 
ное время. 

В главном примере книги мы рассмотрим тот период времени в проек- 
те, когда формальный и грамотный процесс управления изменениями 
особенно необходим. Как только изменение в том или ином элементе 
проекта с большой вероятностью начинает оказывать существенное воз- 
действие на другие элементы, проектная группа в полном составе должна 
тщательно рассмотреть каждое предлагаемое изменение. 


Джамал готовит и согласовывает план 


Джамал Браун, тест-менеджер компаний ЗоЁмаге Саїсгегіа, большую 
часть рождественских каникул отсутствовал на работе. Однако он иногда 
заглядывал в сеть, чтобы прочитать отчеты об ошибках, уточняя предла- 
гаемые приоритеты после совещания с авторами отчетов. Он также об- 
новлял информацию об отслеживании тестовых сценариев в ходе еже- 
дневных телеконференций с тестировщиками, которые работали во 
время каникул. 

Кроме того, он потратил время на изучение самых последних запро- 
сов на изменения проекта “Суматра”. Они хранились в той же базе дан- 
ных, которая применялась для управления дефектами, но были помече- 
ны как запросы на изменения. Конечно, иногда запрос на изменение 
становился ошибкой и наоборот, но с точки зрения управления измене- 
ниями между ними не делалось больших различий. Все новые запросы на 
изменения и отчеты об ошибках, по крайней мере, касающиеся проекта. 
“Суматра”, выносились трижды в неделю на рассмотрение группы управ- 
ления изменениями. 


№ этапа Этап Выполнено? 


1. Соберите запрашиваемые изменения и исправления ошибок, м 
предлагаемые для включения в текущую, будущую или в ава- 
рийную версию системы. 
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Большинство изменений казались весьма незначительными, напри- 
мер новый экран помощи. Некоторые были существенными, в частности 
мастер создания счета в системе управления документооборотом из про- 
дукта Зрееду\Мтикег. Да, думал Джамал, похоже, здесь потребуется объем- 
ное тестирование на совместимость, если учесть, что мы поддерживаем 
различные системы управления документооборотом. 

Одно из предлагаемых изменений было одновременно весьма привле- 
кательным, сложным в реализации и определенно очень рискованным. 
Мухаммед Аджами, работающий в группе продаж компаниям Еопипе 
1000 и государственным учреждениям, предложил, чтобы ЗоЁмаге 
Саїегегіа начала работать в качестве поставщика прикладных услуг (АЅР). 
Он сказал, что некоторые из его клиентов, сытые по горло высокой стои- 
мостью владения и низкой надежностью систем на базе персональных 
компьютеров, ищут выход в виде тонких клиентов, например браузеров и 
информационных приложений, чтобы снизить затраты и увеличить на- 
дежность. Эти заказчики постоянно спрашивают, нет ли возможности пе- 
редать субподрядчикам непрерывную поддержку требований к сервер- 
ной стороне. Вместо того чтобы поддерживать работу большого числа 
серверов, которые необходимы для нормальной работы пакета 
ОйсеАггом в их среде, он хотят приобретать такую услугу у поставщика 
прикладных услуг. Мухаммед предложил, чтобы Ѕоймаге Сабегегіа вос- 
пользовалась такой возможностью, начиная с “Суматры”. 

Это был бы отличный и к тому же уникальный ход. Джамалу не было 
известно ни об одном провайдере прикладных услуг, который предлагал 
бы вкачестве приложений офисные пакеты. Возможно, что об этом пока 
никто не задумывался, либо это была совершенно ужасная идея. Либо эта 
идея не так ужасна, однако ужасно трудно ее осуществить. 

Джамал решил провести к началу совещания группы управления изме- 
нениями неформальный анализ рисков. В ходе анализа рисков в первую 
очередь он обращал внимание на риски качества, но не забывал и про ос- 
тальные риски. Когда Джамал завершил анализ, предложение Мухаммеда 
насторожило его еще больше, поэтому он решил разослать документ, по- 
лучившийся в результате анализа рисков, до совещания группы управле- 
ния изменениями и предоставить его также на совещании. Поскольку 
могло показаться, что он сурово критикует Мухаммеда, Джамал решил 
сначала отправить письмо ему. 


Привет, Мухаммед! 


Надеюсь, ты отлично провел праздничную неделю. Я немного поработал на 
этой неделе, ничего серьезного. Я также просмотрел новые запросы на из- 
менения. 


Должен сказать, что я весьма впечатлен и заинтригован твоим предложени- 
ем по поводу нашего участия в предоставлении прикладных услуг, начиная 
с Суматры. Однако я провел небольшой анализ рисков и выявил несколько 
проблем, связанных с тестированием. Я собираюсь обнародовать эти сооб- 
ражения в понедельник в ходе совещания группы управления изменениями, 
но мне хотелось бы показать их сначала тебе, чтобы ты не чувствовал, 
что на тебя нападают исподтишка. Пожалуйста, посмотри прикрепленный до- 
кумент. Я разошлю этот документ по электронной почте в понедельник ут- 
ром перед совещанием. Если ты обнаружишь неточности или захочешь обсу- 
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дить документ до его рассылки, пожалуйста, не стесняйся: позвони мне 
домой (830) 438-4830 или пришли электронное сообщение. 


С уважением, 


Джамал 


В понедельник утром Мухаммед не ответил, поэтому Джамал разослал 
документ членам группы управления изменениями. В состав группы вхо- 
дили вице-президент по поддержке разработок Джон Албертсон, вице- 
президент по системной разработке Гарольд Джоунз, менеджер разра- 
ботки новой версии Дженни Кауфман, менеджер по маркетингу продукта 
ЅреедуМтгіѓег Кейт Эрнандес, менеджер системных операций и админист- 
рирования Кейт Ли, менеджер поддержки пользователей Косимо Негра- 
ев, менеджер подготовки сборок Ясухиро Канагава, а также заинтересо- 
ванные представители группы продаж. Джамал также включил в список 
рассылки генерального директора Зобугаге Саѓеѓегіа Раджеша Гупту, ко- 
торый собирался быть на совещании, чтобы выступить по вопросу о 
слишком большом количестве отложенных ошибок. 

Совещание началось в 14.00. Кейт Эрнандес, как спонсор проекта “Су- 
матра”, председательствовала на совещании. В повестку дня входили об- 
суждение новых отчетов.об ошибках, новых запросов на изменение и, на- 
конец, любых обновлений, связанных с реализацией исправлений и 
запросов на изменения. 

За последнюю неделю накопилось довольно приличное количество 
необработанных отчетов об ошибках. Поскольку был только первый по- 
недельник, когда сотрудники вернулись после праздников, никто не про- 
смотрел все отчеты. Постоянно задавались вопросы: “О чем этот отчет? 
Я еще не успел его прочесть”, и тратилось довольно много времени на об- 
суждение, стоит исправлять ошибки или отложить их. Увидев, что сове- 
щание начинает выходить из-под контроля, Кейт вмешалась. 

“Послушайте, — сказала она. — Я понимаю, что все заняты, но времени 
не прибавится, если мы будем по два-три раза возвращаться к обсуждению 
одних и тех же ошибок и запросов на изменения. Позвольте мне напом- 
нить вам три фундаментальных правила группы управления изменения- 
ми. Первое -- все приходят на совещание, подготовившись. Совещания 
слишком затягиваются, если для каждой ошибки и каждого запроса на из- 
менение требуется проводить специальную пресс-конференцию. Если со- 
вещания затягиваются, люди прекращают их посещать, а затем мы по- 
ставляем продукт с ошибками. Помните ЗреедуМтиег 2.7? Второе — мы 
тратим на обсуждение одной ошибки или одного запроса на изменение не 
более пяти минут. Я пытаюсь добиться, чтобы наши совещания длились 
не больше часа (сегодня мы уже перекрываем этот отрезок времени, по- 
скольку еще есть ошибки и запросы на изменения), но это возможно толь- 
ко втом случае, если мы не будем отвлекаться на другие темы. Если кто-то 
хочет говорить больше пяти минут об ошибке или изменении, чтобы при- 
нять решение, мы переносим рассмотрение этой ошибки или изменения 
на отдельное совещание. Наконец, помните, что мы принимаем решение 
о том, реализовать или отвергнуть изменение, только один, а не два и не 
три раза. Кроме того, мы стремимся принять решение на совещании, бли- 
жайшем к моменту помещения ошибки или запроса на изменение в систе- 
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мууправления дефектами. У нас нет ни времени в этом проекте, ни сил на 
остановку анализа, долгие задержки в рассмотрении запросов и гамлетов- 
ские дебаты. Время идет, пока мы здесь сидим, что лишает нас простран- 
ства для маневра, поэтому давайте принимать решения, пока у нас еще 
есть выбор". | 

Раджеш, сидевший сзади и предоставивший Кейт функции по укроще- 
нию строптивой аудитории, спросил с улыбкой на лице: “Гамлетовские? 

“Чинить иль не чинить — вот в чем вопрос, достойно ль смиряться под 
ударами рассерженных заказчиков иль... “— пояснила Кейт. 

“Понятно”, — сказал Раджеш. 

“Итак, — резюмировала Кейт, — в следующий раз совещание состоится 
уже в Новом году, верно? Я бы хотела, чтобы в Новом году мы вернулись к 
четким и компактным совещаниям группы управления изменениями, кото- 
рые у нас были до каникул. Что касается оставшейся части сегодняшней 
встречи, я попрошу поднять руки тех, кто прочитал отчет об ошибке или 
запрос на изменение до начала его обсуждения. Если голосование не будет 
единогласным, мы отложим обсуждение этого вопроса до пятницы”. 

Поворчав, группа управления изменениями выбрала более эффектив- 
ный способ работы. Наконец они добрались до запроса на изменение 72, 
посвященного предоставлению прикладных услуг. “Все ли прочитали 
этот запрос на изменение? — спросила Кейт. 

Все подняли руки. Это не было случайным совпадением, поскольку 
Джамал отправил голосовое сообщение с подтверждением получения, 
попросив всех прочитать электронную почту. Он не получил подтвержде- 
ния от Мухаммеда, поэтому позвонил ему. Мухаммед признал, что прочи- 
тал письмо Джамала. Хотя оно неслишком его обрадовало, он согласился, 
что замечания необходимо представить аудитории. 

“Хорошо, — сказала Кейт. — Насколько я понимаю, этому вопросу уже 
уделил немного внимания наш бесстрашный тест-менеджер. Я поговори- 
ла с Дженни, и хотя ей не кажется, что реализация слишком сложна, она 
склонна согласиться с замечаниями Джамала по поводу рисков”. 

Кейт Ли добавил: “Ясухиро, Косимо и я обсудили за обедом анализ 
Джамала, мы тоже согласны с ним”. 

“Хорошо-хорошо, попридержи коней, — попросила Кейт. - Мухаммед, 
по повестке дня ты как инициатор имеешь право выступить первым 
и представить запрос. Обычно мы спрашиваем мнение всех по кругу, но 
я думаю, что Джамал будет основным оппонентом”. 

“Нет, - встревожился Джамал, – я неоппонент. Я просто обеспокоен...” 

“Конечно, ты обеспокоен, ты же тест-менеджер. Не за это ли мы тебе 
платим?” — спросила язвительно Кейт. 

“За это больше, чем обычно”, — сказал Джамал с улыбкой. 

“Я думал, что буду выступать первым”, — сказал Мухаммед, немного раз- 
дражаясь. 

“Прости, ты прав, пожалуйста, бери слово”. 

“Хорошо. Итак, я обсуждал Суматру с несколькими клиентами из числа 
Когіипе 1000 и правительственных организаций. Они действительно 
одобряют общую концепцию Суматры, но обеспокоены общей стоимо- 
стью владения. Одна из причин, по которой они предпочитают пакет 
ОЁЯсеАггом, состоит в том, что им не нужно инсталлировать приложение 


476 


Часть №. Совершенствование 


на каждой рабочей станции, что было бы кошмаром для большой компа- 
нии. И им нравится идея системы управления документооборотом. Это 
пока довольно большое препятствие, особенно для больших юридиче- 
ских фирм. Но им не нравится мысль о необходимости оплачивать нод- 
держку и сопровождение сложной конфигурации серверов. Некоторым 
нашим клиентам довольно непросто поддерживать трехзвенную конфи- 
гурацию серверов. А теперь мы говорим о необходимости еще большего 
количества персонала для поддержки. Полагаю, что мы можем потерять 
некоторые потенциальные продажи. 

Вот тогда и появилась у меня идея о том, не могли бы мы стать провай- 
дерами прикладных приложений. Вместо того чтобы наши клиенты сами 
поддерживали и сопровождали свои серверы, мы создаем централизован- 
ную группу серверов и сопровождаем некоторое число клиентов. Вся тех- 
ническая экспертиза будет располагаться внутри нашей компании, поэто- 
му им не нужно будет нанимать специалистов. Это было бы уникальное 
предложение. Судя по разговорам потенциальных клиентов, по моим 
оценкам, мы могли бы легко получить не менее 1 миллиона долларов при- 
были в течение первого года только с учетом тех компаний, которые уже 
заинтересованы в таком виде услуг. Если это технически не очень сложно 
реализовать (и, судя по реакции Дженни, это действительно несложно), 
я бы сказал, что мы должны попытаться это сделать”. 

Кейт кивнула, а затем обратилась к Джамалу: “Джамал?” 

“Отлично, — сказал Джамал, — начну с того, что мне действительно 
нравится идея Мухаммеда. У меня нет никакого желания быть “Мистером 
Нет” на этих совещаниях, и я полагаю, что меня нельзя обвинить в непра- 
вильном подходе кобсуждению запросов на изменения. Однако я считаю, 
что время этой отличной идеи еще не наступило. 

Сегодня утром я отправил этот документ каждому из вас, — сказал Джа- 
мал, начиная раздавать копии, — думаю, что вы знакомы с содержанием. 
Это анализ рисков и последствий, который я провел после того, как про- 
читал и обдумал предложение Мухаммеда. Я классифицировал различ- 
ные проблемы по категориям рисков качества — тем же категориям, кото- 
рые мы использовали при проведении первоначального анализа рисков 
качества с применением инструмента анализа видов ошибок и их влия- 
ния, азатем я проранжировал все риски на основе интуиции и других точ- 
ных научных приборов, —он улыбнулся. — Я использовал ранги "очень вы- 
сокий”, “высокий”, “средний”, “низкий” и “очень низкий”. Не собираюсь 
занимать ваше время изучением “средних” и более низких рангов. Вы мо- 
жете прочесть документ, если хотите узнать подробности. Но позвольте 
мне кратко обрисовать пять основных проблем. 

Во-первых, в области эксплуатации и сопровождения я оцениваю рис- 
ки проблем, которые могут угрожать непрерывной работе, как очень вы- 
сокие. Мы должны будем создать, протестировать и поддерживать замы- 
словатые сетевые операции и сложный центр данных. Я ранее работалу 
провайдера Интернет-служб и могу сказать, что технически это далеко не 
простая задача”. Кейт Ли кивнул, а Джамал продолжал: “С точки зрения 
следствий для тестирования, мы должны создать тестовую среду, которая 
повторяет среду эксплуатации или, по крайней мере, очень близка к ней, 


` что будет, без сомнения, дорогим и не простым с организационной точки 


Глава 16. Увеличение возможностей для обучения 477 


зрения для группы тестирования и для эксплуатации. С точки зрения 
следствий для бизнеса, у нас будут высокие первоначальные затраты и за- 
траты на непрерывные операции, включая анпаратное и программное 
обеспечение, сетевое оборудование и персонал. Мы можем легко тратить 
миллион долларов в год только на поддержку центра данных и системы в 
рабочем состоянии. 

Во-вторых, что касается совместимости, отказов в работе оборудова- 
ния, операционной системы, браузера и сервера, здесь риски и влияние 
очень высоки. Для Когіипе 1000 и правительственньх организаций при- 
дется хранить огромные объемы данных. Стоимость Мемогк Ацаспей 
Ѕгогаре — от $25 тыс. до $250 тыс. на конфигурацию, а Зюгаре Арріапсе 
МесмогК$ — от $1 млн. Так что мы получаем очень дорогую тестовую среду 
и очень сложную операционную среду. 

В-третьих, я думаю, что мы столкнемся с очень высокими рисками, 
связанными с безопасностью и секретностью. Клиенты будут справедли- 
во рассчитывать, что их документы никогда не увидят другие клиенты. 
Для тестирования это означает существенное увеличение тестовых сце- 
нариев безопасности. С точки зрения бизнеса, в случае каких-либо инци- 
дентов в этой области мы можем столкнуться с серьезными исками. 

В-четвертых, неизвестна степень рисков с точки зрения конкуренции. 
Могу только предположить, что клиенты будут сравнивать нас с другими 
провайдерами в других сферах предоставления услуг, но последствия это- 
го сейчас неочевидны. В-пятых, я думаю, что мы столкнемся с высокими 
рисками и серьезными последствиями, связанными с областью качества 
данных — проблемами с обработкой, хранением и извлечением данных. 
Наши клиенты будут справедливо полагать, что мы в состоянии безопас- 
но хранить их данные, включая восстановление данных после сбоев и 
восстановление файлов при их случайном удалении. С точки зрения тес- 
тирования, это не так серьезно. Мы просто расширим существующие тес- 
товые сценарии, чтобы проверить различные ситуации, связанные с пре- 
доставлением услуги доступа к прикладным программам. Однако для 
бизнеса последствия являются пугающими, особенно с точки зрения воз- 
можных исков, если данные клиента бесследно исчезнут. 

Итак, я уже сказал, что выбрал пять основных проблем. Я также хочу 
упомянуть производительность, доступность и стабильность. Наши кли- 
енты, очевидно, будут ожидать очень качественных решений по этим по- 
зициям, не так ли? А тестирование производительности среды большого 
центра данных потребует не только соответствующей по размерам и воз- 
можностям тестовой среды, но и гораздо большего числа лицензий на ин- 
струменты, чем я имею сейчас. Кроме того, я неуверен, что смогу провес- 
ти к марту месяцу тестирование наработки на отказ". 

“Тестирование наработки на отказ?” — переспросил Мухаммед. 

“Извини, это точное статистическое измерение того, как часто систе- 
ма будет терпеть крах. Похоже на рекламную акцию про 99.999%, которая 
прошла недавно”. 

Некоторое время стояла тишина. Все смотрели по сторонам. 

“Отменная презентация, — признал Раджеш. — Вероятно, ты имеешь 
в виду, что нам придется построить как минимум два центра данных, 
один — для работы, второй — для тестирования”. 
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“Да, это так”, — ответил Джамал. 

“Почему?” — спросил Раджеш. 

“Потому что довольно скоро нам потребуется обновить программы в 
рабочем центре данных либо новыми версиями пакета ОЁйЙсеАггом, либо 
другими компонентами. Нам нужно будет тщательно тестировать новые 
конфигурации перед тем, как мы передадим их в эксплуатацию, посколь- 
ку доступность системы — это очень важный вопрос”. 

“Согласен, но, — продолжал настаивать на своем Раджеш, — почему 
нельзя использовать уменьшенную модель рабочей конфигурации”. 

“Она подойдет для функционального тестирования, — согласился Джа- 
мал. — Однако ошибки надежности, производительности, качества дан- 
ных и совместимости обычно не проявляют себя вуменьшенных моделях 
так же, ках в настоящих конфигурациях. Вот пример. Пусть я выполняю 
тестирование производительности в уменьшенной конфигурации серве- 
ра и обнаруживаю, что производительность падает до неприемлемой ве- 
личины при обслуживании 100 пользователей. В эксплуатационной среде 
имеются процесс, работающий впятеро быстрее, диск, емкость которого 
в пять раз больше, и память, также больше в пять раз, чем в тестовой сре- 
де. При каком количестве пользователей производительность в рабочей 
среде снизится до неприемлемых величин? При 500? При 2500? Или при 
125002 

Раджеш рассмеялся и ответил: “Я вряд ли смогу ответить на этот во- 
прос. Но я знаю, в компании есть умные технические специалисты, кото- 
рые знают ответ, верно?” Он посмотрел на присутствующих. 

“Да, - с неохотой вставила Дженни, — мы можем построить динамиче- 
ские статистические модели для производительности системы. Мы уже 
делали это для предыдущих версий. При проверке модели в идентичных 
конфигурациях среды мы могли получить результаты, довольно близкие 
к реальным. Эти модели постепенно приближались к идеалу, однако мы 


‚фактически никогда ими не пользовались. Проблема с моделированием 


такого сорта состоит в том, что нужно знать, где находятся узкие места, 
нужно уметь предвидеть экстремумы кривой производительности и вы- 
бирать подходящие статистические распределения (формулы плотности 
вероятности) для каждого ресурса... — голос Дженни затих, она погрузи- 
лась на минуту в проблемы. — В любом случае есть много деталей, и если 
не уследить за какой-либо из них, забыть хотя бы одну или неверно ис- 
пользовать в модели, вы получите не результаты тестирования, а мусор. 
Единственный способ проверить модель - это тестирование в настоящей 
среде”. 

“Но вы могли бы, — настаивал Раджеш, — будучи очень-очень аккурат- 
ными и очень-очень проницательными, построить модель, которая про- 
веряет усеченную версию и позволяет прогнозировать производитель: 
ность и тому подобное для центра данных, верно?” 

Джамал сказал: “Да, Раджеш, это, конечно, возможно. Аэрокосмиче- 
ские и оборонные компании делают это постоянно. Они серьезно заняты 
моделированием, тестированием усеченных и макетных конфигураций, 
это верно, когда мы говорим о системе вооружения или летательном ап- 
парате. Но представьте тестирование системы противоракетной оборо- 
ны, о которой мы читаем время от времени или видим в новостях. Каж- 
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дый из тестов стоит очень и очень дорого, примерно 100 миллионов дол- 
ларов. Я не сомневаюсь, что перед началом выполнения каждого из тес- 
тов проводится значительная работа по тщательному моделированию. 
Но все равно бывают неудачи. Когда мы говорим о сложной системе в ди- 
намической и непредсказуемой среде, там возможны непредвиденные 
последствия. 

Дженни кивнула: “Джамал прав. Нет другого способа, кроме подробно- 
го тестирования, чтобы понять наверняка, что будет происходить в слож- 
ном центре данных”. 

“Хорошо, если вы не можете получить верные результаты при модели- 
ровании, что заставляет вас думать, что тестирование дает правильные 
результаты? Не являются ли ваши тесты просто моделью того, как пользо- 
ватели применяют систему?” - возразил Раджеш. 

“Раджеш, ты абсолютно прав, но выбор у нас не либо один, либо дру- 
гой, алибо оба, либо только один. Мы могли бы использовать имитацион- 
ную модель, а также статические модели, например таблицы, в обоих слу- 
чаях, — ответил Джамал. — Однако без тестирования мы не можем 
проверить имитационную модель. При наличии требования постоянно- 
го доступа мы принимаем на себя риск “выставления компании на пари”, 
что модели построены правильно, не проверив это заранее. У нас грамот- 
ные сотрудники, Раджеш, — сделал вывод Джамал, — но не настолько. Уве- 
рен, рано или поздно у нас будут большие проблемы. Это рулетка качест- 
ва”. Раджеш осмотрел сидевших в помещении: “Дженни, я думаю, у тебя 
такое же мнение? Кейт Эрнандес? Кейт Ли? Ясухиро? Что думают осталь- 
ные?” 

Все согласно кивали. 

“Хорошо, — сказал Раджеш, откидываясь назад и скрещивая руки за го- 
ловой. — Причина, по которой я так настойчиво продвигал это предложе- 
ние, состоит в том, что я размышлял над этой темой вместе с Мухамме- 
дом, и я поговорил с некоторыми клиентами. Это очень актуальная тема. 
Я также обсуждал этот вопрос на совете директоров и с некоторыми по- 
тенциальными инвесторами. Они действительно горят желанием полу- 
чить что-то подобное, хотя инвесторы, естественно, не намерены тра- 
тить кучу денег прямо сейчас. Они рассматривают переход Зоймаге 
Саѓегегіа от продажи пакета к предоставлению услуг офисных приложе- 
ний как очередной логический шаг в развитии компании”. Раджеш по- 
смотрел вокруг, встретившись с каждым из сидящих взглядом, и добавил: 
“И я тоже". 

Джамал откинулся в кресле. “Однако, — думал он, — я высказал столько 
замечаний по поводу любимого проекта босса. Я думаю, что сейчас пони- 
маю, что он действительно имел в виду, когда говорил о “желании услы- 
шать наши откровенные мнения” на совещании, посвященном запуску 
проекта”. 

"Но я знаю, у нас в компании много талантливых сотрудников, отлич- 
но подготовленных технически, и эти талантливые сотрудники выража- 
ют беспокойство, включая тебя, Джамал, — сказал Раджеш с поддержкой и 
уважением. — Я полагаюсь именно на такой честный и тщательный ана- 
лиз, который ты подготовил по этому вопросу. И я думаю, что твоя работа 
фактически устанавливает стандарт для всех в группе управления. Я не за- 
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бываю ничьих соображений, и помню о сложности работы. Однако я об- 
рисовал стратегическое направление для компании. Возможно, это не- 
подходящее место, и я, вероятно, навлек на себя гнев Кейт по поводу 
повестки дня и правил работы группы”. 

Кейт, внимание которой было поглощено изменениями в стратегии 
компании, ответила не сразу после того, как услышала свое имя: “Нет, во- 
все нет, я так увлеклась. Думаю, что мы можем выделить время на это обсу- 
ждение”. 

“Хорошо, я почти все сказал, — заявил Раджеш. — Есть предложение. 
Мухаммед и я определим два наиболее актуальных направления для про- 
вайдерских услуг. Через два месяца после завершения версии “Суматра” 
я бы хотел перейти к подготовке бета-версии ЅреейуМгііег АЅР для не- 
большого, но функционального центра данных. Мы честно скажем на- 
шим заказчикам, что мы изучаем, как лучше это сделать. Они могут реаги- 
ровать как угодно, но мы не хотим терять данные. Гарольд и Джон, 
я хотел бы, чтобы вы подобрали в своих подразделениях квалифициро- 
ванных людей, которые могли бы набросать план, как это сделать”. Га- 
рольд и Джон согласно кивнули. “Мы можем это сделать, не так ли? 

“Если мы будем внимательны и осторожны, — сказала Дженни, — я ду- 
маю, мы сможем это сделать”. 

“Джамал?” 

“Да, — ответил Джамал. — Для полной уверенности я должен поговорить 
со своими людьми, но как мне кажется, все это в пределах возможного”. 

“Тогда у нас есть план, — помпезно завершил обсуждение Раджеш. — 
Кейт, тебе слово”. 


№ этапа Этап Выполнено? 
2. Обсудите предлагаемые запросы в ходе регулярного или экс- 


тренного совещания группы управления изменениями, при 
помощи электронной почты или на телеконференции. 


ЗА Оцените связанные с запросами получаемые преимущества в 
свойствах, бюджете, сроках и качестве, затраты, проблемы и 
риски реализации, тестирования и выпуска версии. При необ- 
ходимости отложите рассмотрение до очередного совещания 
и получите дополнительную проясняющую информацию. 


2.В Присвойте приоритеты каждому отчету об ошибке или от- | м 


вергните его. 
2.С Идентифицируйте передаваемые материалы реализации, тес- М 
тирования и интеграции версии; оцените даты завершения 
для каждого запроса. 


Совещание продолжилось. Участники перешли к завершению реали- 
зации, тестирования и интеграции изменений и исправлений дефектов, 
которые были ранее утверждены. Ссылаясь на одно из изменений, Джа- 
мал произнес с улыбкой: “Хотел бы всем напомнить после моей недавней 
обструкции о том, что я полностью поддержал это изменение и очень рад 
сообщить, что оно прошло функциональное тестирование и тестирова- 
ние данных без проблем”. 
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№ этапа Этап Выполнено? 


3. Спланируйте, реализуйте, протестируйте и интегрируйте из- ы 
менение или исправление ошибки, отмечая новые затраты, 
преимущества, проблемы и риски. 


4. Представьте результаты реализации, тестирования и интегра- 
ции версии и передаваемые материалы для окончательного 
утверждения. 

4А Оцените предстоящие затраты, преимущества, проблемы 


и риски, относящиеся к свойствам, бюджету, срокам и качеству. 


4.В Сравните преимущества добавления изменения с затратами, м 
проблемами и рисками. 


4.С Примите окончательное решение: одобрить или отвергнуть 
изменение в соответствующей версии. 


5. Если внесение изменения утверждено, включите новые или 
измененные компоненты системы, проектную документацию 
и другие передаваемые материалы в систсму управления кон- 
фигурацией. 


[а] 


Наконец, Раджеш и Косимо представили ошибки, которые, по их мне- 
нию, были отложены до следующей версии напрасно. Примерно десяток 
ошибок были открыты заново. 

“Джамал, — сказал Раджеш, завершая обсуждение, — спасибо за то, что 
ты подал мне идею просмотреть эти ошибки. Десять — небольшое число, 
но некоторые из них действительно существенны”. 

“Рад помочь, Раджеш”, — ответил Джамал. 

“В целом, — подвел итог Раджеш, — сучетом примерно тысячи ошибок, 
обнаруженных к настоящему времени, я думаю, что мы отлично справля- 
емся с динамикой этого проекта. Я вижу, что большим подспорьем явля- 
ются и это совещание, и весь процесс управления изменениями. Я призы- 
ваю всех вас поддерживать его”. 


Взаимосвязанный процесс 


“Отлично, — скажете вы, — я понимаю, что процесс управления измене- 
ниями является ключевым, но является ли он процессом тестирования?” 
Это верное замечание. В отличие от одиннадцати процессов, описанных 
в этой книге, процесс управления изменениями относится в основном к 
ведению группы управления проектом. Другими словами, в процессе 
управления изменениями группа тестирования — это только один из уча- 
стников. Группа тестирования не является ни основным, ни наиболее ак- 
тивным его участником. 

Однако процесс управления изменениями оказывает сильное влияние 
на группу тестирования, а также на группы разработки и сборки версий. 
Процесс управления изменениями воздействует на все процессы тести- 
рования. Процесс подготовки тестовых версий передает сборки с новым 
и исправленным содержимым. Процесс выполнения тестов проверяет 
новое и исправленное содержимое. Процесс подготовки отчетов об 


482 


Часть №. Совершенствование 


ошибках выявляет конкретные проблемы в изменениях или исправлени- 
ях. Наконец, процесс подготовки отчетов о результатах тестирования пе- 
редает информацию группе управления изменениями, чтобы ее участни- 
ки могли принять решение, утвердить или отвергнуть изменение или 
исправление. Без эффективного управления изменениями все эти про- 
цессы работают менее эффективно и качественно. 

В самом деле, в некоторых обстоятельствах процесс управления изме- 
нениями может отправить группу тестирования к начальным процессам, 
связанным с подготовкой тестирования. В нашем примере Джамал в ходе 
подготовки к совещанию проводит анализ рисков качества. В результате 
утверждения изменения в ближайшей версии Джамал вновь возвращается 
к процессам оценки затрат и планирования для того, чтобы рассмотреть 
введение услуг провайдера прикладных приложений для ЅреейуМгігег. 
Чтобы протестировать это предложение, группе тестирования, вероятно, 
понадобится спроектировать и разработать новые тесты. В случае если для 
выполнения этих тестов требуются специальные навыки или дополнитель- 
ные тестировщики, у Джамала может возникнуть потребность принять на 
работу новых постоянных сотрудников или контрактников. В реальности 
для разработки услуг провайдера прикладных приложений может понадо- 
биться отдельный процесс тестирования. Другими словами, версия про- 
вайдера прикладных приложений для Суматры будет отдельным проек- 
том, а тестирование этой версии — подпроектом в рамках этого проекта. 

Поэтому участие группы тестирования в процессе управления измене- 
ниями очень заметно, особенно когда тест-менеджер, такой как Джамал, 
привносит в него заслуживающую доверия конкретную информацию, 
чтобы прояснить тему рисков качества, связанных с изменениями. Про- 
цесс оказывает существенное влияние на способность группы тестирова- 
ния приносить пользу проекту, и это влияние тем больше, чем больше 
число изменений, нуждающихся в управлении. Наконец, последствия не- 
удачи этого процесса оказывают сильное воздействие на успех группы 
тестирования. Если нам неизвестно, в каком состоянии находится проект 
на заключительной стадии, то, очевидно, мы сделали что-то неверно 
в ходе тестирования. И наоборот, когда тест-менеджер, например Джа- 
мал, берет все под контроль, участие группы тестирования в этом процес- 
се способствует успеху проекта. 


Построение успешного процесса управления 
изменениями 


Процесс управления изменениями довольно сложен. Однако грамотный 
процесс управления изменениями позволяет группе проекта сделать пра- 
вильный выбор. 


і Необходимо честно признать, что данная глава представляет взгляд на управление измене- 
ниями с позиции тестирования. Более широкий взгляд с позиции управления проектом долж- 
ны принимать во внимание образованные тестирогшики-профессиональі, поскольку он явля- 
ется частью понимания контекста проекта. Неплохой источник для изучения такого взгляда на 
процесс — книга Стива Макконела “Зойиате Руојесї Зипли Сийй, особенно глава 6. 
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Выбор нужных изменений в нужном порядке 


Время идет и в жизни, и в проекте. Каждый день работы в проекте мы 
видим безжалостное движение времени к запланированной дате завер- 
шения проекта. Каждый день работы в проекте мы неизбежно истоща- 
ем его бюджет. Располагая меньшим количеством времени и денег, мы 
сталкиваемся с возрастающими рисками неудачи проекта, если рабо- 
чая группа проекта занимается не тем, чем нужно. Поэтому наиболее 
важный вопрос состоит в следующем: делаем ли мы сейчас то, что нуж- 
но, чтобы вести проект по направлению к наиболее успешному завер- 
шению? С точки зрения управления изменениями, вносим ли мы нуж- 
ные изменения, корректируем ли курс в верном направлении, тратим 
ли наиболее ценные и невозобновляемые ресурсы проекта в нужном 
порядке? 

Во многих проектах, в которых я работал, в периоды выполнения 
тестов существовал непрерывный цикл. Мы вносили изменения в опре- 
деление проекта в ответ на новую информацию о свойствах, бюджете, 
сроках и качестве. Мы тестировали внесенные изменения, в результате 
получали еще информацию, в частности о качестве. Этот цикл продол- 
жается до тех пор, пока группа управления проектом не примет решение 
о том, что критерии завершения фазы тестирования выполнены. На за- 
ключительной фазе тестирования, системного тестирования или прие- 
мо-сдаточных испытаний это решение также включает в себя решение 
о выпуске или поставке системы. Это тонкое и взвешенное решение. 
Превосходят ли риски, связанные с отсрочкой выпуска или поставки 
системы для внесения очередного исправления или усовершенствова- 
ния и проведения тестового цикла, риски, связанные с поставкой систе- 
мы с известными ошибками, без отложенных усовершенствований или 
незаконченных свойств?! 

Поскольку недостаток времени отнимаету нас возможности для ма- 
невра, большое значение приобретает способность принятия реше- 
ний. Читая эту главу, мой коллега тест-менеджер Харви Дойч сказал об 
этом так: “Не разрабатывай то, что ты не собираешься тестировать. Не 
тестируй то, что ты не собираешься выпускать. [Урезай] как можно 
раньше и чаще”. Другими словами, в контексте полного тестирования, 
является ли то, над чем работает группа тестирования прямо сейчас наи- 
более важной совокупностью задач для достижения полного успеха 
проекта? Группа управления изменениями, составленная из специали- 
стов разных направлений и использующая в качестве основы для своей 
работы результаты тестирования, может дать разумные рекомендации 
по рассматриваемому вопросу руководству компании и старшим менед- 
жерам. 


1 Вкниге “ГАта Вир” Роберт Сабурин пишет, касаясь вопроса оставшихся ошибок, рас- 


сматриваемых группой управления изменениями: "Ми считаем, что завершили работу, если 
оставшиеся ошибки — это ошибки, с которыми мы можем сосуществовать, по крайней мере, 
сейчас! р 
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Уравновешивание мнений по поводу свойств, сроков, бюджета 
и качества 


Группа, состоящая из специалистов разного профиля, идеальна для реше- 
ния этого вопроса, поскольку сам вопрос, безусловно, охватывает различ- 
ные сферы ответственности и должен рассматриваться с учетом много- 
численных факторов. В этот перечень входят: 


ш Экономика, зависимости и задачи, связанные с реализацией, тести- 
рованием и интеграцией изменения или исправления ошибки 
в версию. 


ш Возможности и риски, затраты и преимущества предлагаемого из- 
менения или исправления ошибки. 


и Возможности и ограничения группы управления изменениями как 
с точки зрения трудозатрат, так и квалификации. 


и Последнее, но не менее важное. Ключевые соображения бизнеса 
и технические проблемы, включая архитектуру системы, будущие 
требования и долгосрочное направление развития системы, груп- 
пы проекта и компании в целом. 


Слишком часто на совещаниях групп управления изменениями в ходе 
обсуждения исправления ошибок доминирует один вопрос. Страстные 
аргументы высказываются по поводу того, верно ли определена серьез- 
ность той или иной ошибки, в частности, серьезность | или серьез- 
ность 2. Обычный подтекст этой дискуссии состоит в том, что рассматри- 
ваются только ошибки серьезности 1. Но в сравнении с другими 
факторами, особенно стратегическими проблемами бизнеса, эти дискус- 
сии не по существу. То же самое относится и к обсуждению того, стоит ли 
реализовывать предлагаемое изменение. 

Принимая решение о том, исправлять ошибку или нет, реализовывать 
изменение или нет, проектные группы должны принимать к рассмотре- 
нию, как соответствующие состояния ошибок или отсутствие изменений 
повлияет на заказчиков и пользователей, поскольку они являются единст- 
венными арбитрами качества. И наоборот, группа тестирования должна 
учитывать, каким образом проявятся риски, связанные с внесением изме- 
нения или исправлением ошибки, но с точки зрения общего контекста 
проекта. В рассмотренной нами ситуации представление рисков Джама- 
лом — это один из важнейших технических и экономических вопросов, 
относящихся к риску реализации изменения. Стратегическое направле- 
ние развития компании, самые серьезные соображения бизнеса сделали 
это решение верным для бизнеса. Однако план Раджеша по продвижению 
в этом стратегическом направлении был немного приостановлен, а риск, 
присущий этому плану, смягчен, благодаря рассмотрению соображений 
Джамала. 

В результате мы подошли к ключевому уроку, неявно вытекающему из 
всего примера: процесс должен предоставлять всем заинтересованным 
лицам и участникам возможность высказать свою точку зрения. В некото- 
рых неудачных проектах процесс управления изменениями сопровож- 
дался вспышками раздражения. Одна-две фигуры руководителей змоцио- 
нально провозглашают, какое значение имеет предлагаемое изменение 
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или исправление ошибки, и игнорируют как обструкционистские так 
и, что еще хуже, реально существующие возражения и риски, представ- 
ленные кем-либо еще. 

Конечно, высшее руководство и старшие менеджеры имеют право, 
а в некоторых случаях просто обязаны отклонить решение группы управ- 
ления изменениями. Старшие менеджеры и топ-менеджеры компании ви- 
дят общую картину, что является их непосредственной обязанностью. 
Однако они обычно следуют грамотным советам, как дальше двигаться 
вперед с учетом смягчения, а не игнорирования реальных проблем и рис- 
ков. Поступать наоборот — это значит отказаться от вклада талантливых 
непосредственных исполнителей и линейных менеджеров проектной ко- 
манды. Это равносильно вождению автомобиля ночью с выключенными 
фарами. 

Важно, чтобы все участники, включая непосредственных исполните- 
лей, имели более общее представление об организационном и стратеги- 
ческом контексте, в который встроен проект. Если у группы управления 
изменениями отсутствует общая повестка дня, группа не представляет со- 
бой ничего иного, кроме политической организации, предназначенной 
для разрешения конфликтов между различными спорящими сторонами. 
Люди с большей вероятностью придут к схожему представлению об об- 
щем уровне риска, об оценке значения каждого риска и о преимуществах 
проекта в целом, если они имеют общий взгляд о направлениях развития 
проекта и компании. Другими словами, грамотный процесс управления 
изменениями устроен так, что его участники вырабатывают и обосновы- 
вают свои советы и решения в пределах общего видения будущего. 


Решение проблем 


В процессе управления изменениями существует ряд проблем, присущих 
проекту тестирования в целом. Рассмотрим те из них, которые относятся 
непосредственно к управлению изменениями. 


Сложная природа воздействия изменений 


Поскольку не все изменения и исправления ошибок равноправны по 
уровню риска, сопровождающего каждый из четырех элементов проекта, 
не все изменения и исправления ошибок оказывают одинаковое воздей- 
ствие на различные группы. Изменение, в результате которого исправле- 
на единственная строка кода, может потребовать от прилежного про- 
граммиста потратить часы и даже дни, чтобы удостовериться, что 
изменение не вредит ничему другому в системе. Изменение, которое тре- 
бует серьезной работы программиста, может быть тривиально для тести- 
рования и для поддержки рабочей среды, но может оказаться сложным и 
требующим серьезных затрат времени от группы сборки версий для того, 
чтобы интегрировать изменение в сборку, а также для технических писа- 
телей, чтобы документировать изменения. Возможны и другие варианты. 
Даже при грубой оценке затрат на изменение, скажем, при разбиении за- 
трат на небольшие, средние и крупные для каждой из пяти групп: разра- 
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ботки, тестирования, операций, сборки версий и технической докумен- 
тации, — существует 243 различных комбинации возможного 
распределения затрат. 

Так, в проекте по разработке Интернет-приложения несколько раз 
упоминалась разработка комплекта тестовых сценариев для ручного тес- 
тирования, которые, среди прочего, тестировали последовательность 
действий с экранами. Экраны были реализованы на НТМІ, для просмотра 
в браузере, что являлось развитой архитектурой для клиентских машин. 
Тестирование с помощью эксплуатационных тестов удобства использова- 
ния показало, что пользовательский интерфейс неудобен и неэстетичен. 
Поэтому разработчики пользовательского интерфейса пришли в один из 
выходных и полностью переработали его. В понедельник утром мы полу- 
чили новую тестовую версию, в которой был абсолютно другой пользова- 
тельский интерфейс. Когда я объяснил разработчикам интерфейса, что 
их изменения, несмотря на хорошее качество, могут вынудить нас пере- 
работать многие из тестов, они не поверили. “Почему? — спросил один из 
инженеров. — Это же просто ссылки!” з 

Как правило, группы управления изменениями ошибочно предпола- 
гают, что изменение, не оказавшее сильного воздействия на одну из 
групп, по всей вероятности, не окажет сильного воздействия и на все 
остальные группы. Мой опыт показывает, что за точку отсчета обычно 
принимают влияние изменения на группу разработки. Если изменение 
требует серьезных усилий от программистов, руководство склонно 
поддержать соответственно большие затраты на тестирование. Если 
затраты на разработку малы, руководство скептически относится к 
идее значительного увеличения сроков или бюджета на тестирование 
изменения. 

Однако не относится ли это допущение линейной зависимости между 
затратами, необходимыми программистам, и затратами остальных 
групп, работающих над проектом, к старым заблуждениям, связанным с 
соотношением тестировщиков и разработчиков, упомянутым в главе 3? 
Если мы предположим, что затраты учеловеко-часов на тестирование со- 
ответствуют затратам хчеловеко-часов на г резрабочку; то получим следую- 


щую формулу: 
у= Вх, 
где Ё —– постоянная, например равная 


2 РВжРирЛвшиЊа 
5 раБраЖЛР иЊЛе 


В результате мы снова вернемся к использованию отношения между 
числом тестировщиков и разработчиков в качестве метода оценки за- 
трат. Как уже отмечалось в главе 8, эти отношения могут быть полезны 
для дополнительной проверки декомпозиции работ, но не в качестве ос- 
новного метода. 

На самом деле, в этой ситуации такие соотношения еще менее полез- 
ны. Почему? 
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В большом проекте закон больших чисел сглаживает все крайности. 
Когда мы говорим о небольшом изменении или об исправлении ошибки, 
разность в измерениях затрат тестирования и разработки часто весьма 
значительная. 

Эта проблема еще раз указывает на необходимость включения в про- 
цесс управления изменениями специалистов разных направлений, а так- 
же их участия на этапах процесса, цель которых дать реалистичную оцен- 
ку воздействия изменения на каждую группу, занятую в проекте. 
Грамотный процесс управления изменениями должен предусматривать 
тщательное рассмотрение влияния изменения на каждую группу до при- 
нятия решения. 


Волнообразный эффект изменений 


Помимо необходимости переработки тестовых сценариев (см. выше), 
другим существенным источником нелинейной зависимости между затра- 
тами на тестирование и разработку является волнообразное влияние из- 
менений на систему. В некоторых случаях изменение затрагивает компо- 
нент системы, который является центральным для всех остальных 
элементов системы. 

Под эту категорию обычно подпадают данные и метаданные в цен- 
тральной базе данных. В предыдущей главе упоминался проект, в кото- 
ром одна группа разработки утверждала, что созданный ею компонент 
системы обладает всеми запланированными свойствами. Однако от вер- 
сии к версии они продолжали изменять схему мастер-таблицы, в которой 
хранилась информация о пользователях. Это изменение оказывало такое 
же влияние на тестирование, как добавление или удаление свойств, по- 
скольку каждое поле было привязано к изменениям пользовательского 
интерфейса и к модификациям в последовательности действий и тран- 
закций, которые, в свою очередь, оказывали воздействие на агентов цен- 
тра обработки вызовов. Кроме того, поскольку четыре из семи других 
подсистем использовали данные из этой базы, изменение воздействовало 
и на них. 

Волнообразный эффект представляет собой отдельную. проблему, 
если система, предназначенная для тестирования, является системой сис- 
тем. Изменения и другие нелинейные воздействия могут волнообразно 
проходить через организационные границы. Другими словами, одна 
группа программистов может посчитать, что сделать изменение в их под- 
системе несложно. Но другие группы программистов, группа тестирова- 
ния и другие участники проекта обнаружат, что предлагаемое изменение 
перевернет все с ног на голову. 

Вновь отмечу, что мы обязаны привлекать специалистов разных на- 
правлений. Группа управления изменениями может выйти за рамки про- 
екта и вовлечь в свою работу представителей, не входящих в проектную 
группу. В случае волнообразного эффекта изменений и исправлений оши- 
бок в стратегических, ответственных и взаимосвязанных системах сис- 
тем может возникнуть необходимость привлечения к участию в группе 
управления изменениями топ- менеджеров компании. 
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Действительное или кажущееся препятствие? 


“Ужасно, — возможно, вы думаете сейчас, — какие неправдоподобные на- 
кладные расходы. Не станет ли процесс управления изменениями огром- 
ным препятствием на пути прогресса? Как мы сможем исправлять ошиб- 
ки и вносить изменения, если мы должны получить одобрение от двух- 
или трехуровневых групп управления изменениями, состоящих из десят- 
ков участников, каждый из которых может вполне быть заинтересован в 
сохранении статус-кво и минимизации объема работ, возложенного на 
уже перегруженные группы?” 

Это верное соображение, и на него нет простого ответа. Управление 
изменениями служит не для создания препятствий изменениям, а для 
того, чтобы убедиться, что для каждого предлагаемого изменения прове- 
ден необходимый анализ перед тем, как запустить его в работу. Любое из- 
менение связано с затратами и рисками, а также с новыми возможностя- 
ми и прибылью. Поэтому все зависит от расположенности компании к 
риску и ее стремления к экономии. 

Компания, которая принципиально отказывается от рисков и стре- 
мится к экономии, вероятно, нуждается в более осторожном процессе 
управления изменениями. Компания, которая больше думаето возможно- 
стях, а нео рисках, и рассматривает затраты, связанные с изменениями, 
как потенциально большие прибыли, обуславливаемые завоеванием 
большей доли рынка, отнесутся к осторожному процессу управления из- 
менениями как к препятствию. Таким образом, организационный кон- 
текст компании имеет значение при определении подходящего уровня 
формализации и тенденции к отсрочке или отклонению изменений. 

В главном примере книги Джамал концентрируется на рисках и затра- 
тах. Раджеш Гупта прежде всего смотрит на возможности и прибыли. Од- 
нако Джамал привлек внимание Раджеша к политике группы управления 
изменениями, которая привела более чем к десятку неверно отложенных 
ошибок. В этом случае Раджеш приняларгументы Джамала, что затраты и 
риски будут слишком высокими. Участники группы управления измене- 
ниями будут до некоторой степени не согласны с политикой в отношении 
изменений. Время от времени группа управления изменениями отступает 
то в одну, то в другую сторону от принятых правил отношения к рискам и 
экономии компании. В самом деле, такие ситуации неизбежны в группе, 
состоящей из сотрудников разных направлений. Попытки устранить не- 
согласие и отклонения от политики в отношении изменений обычно при- 
водят к невозможности проведения анализа частью группы управления 
изменениями. 

Однако последовательные ошибки или перекос водном или другом на- 
правлении, например утверждение чересчур рискованных изменений 
или отклонение изменений, которые соответствуют корпоративным це- 


лям, указывают на проблемы в группе управления изменениями. Как упо- 


миналось ранее, разделяемое всеми представление о будущем является 
ключевым индикатором грамотного процесса управления изменениями. 
Если участники группы управления изменениями не имеют общего пред- 
ставления или не разделяют представления о ситуации с руководством 
компании, группа управления изменениями становится препятствием. 
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Возможно, что группа управления изменениями, все руководители и 
все непосредственные исполнители разделяют общее видение ситуации, 
но группа управления изменениями все еще рассматривается как препят- 
ствие. Если процесс управления изменениями является слишком бюро- 
кратизированным и формальным для корпоративной культуры даже при 
условии, что расстановка приоритетов, критерии отклонения или приня- 
тия изменения четко соответствуют потребностям компании, сотрудни- 
ки могут рассматривать группу как инструмент, предназначенный в ос- 
новном для отклонения или откладывания изменений и исправлений 
ошибок. Вообще говоря, бюрократизм и формальные процессы имеют 
репутацию тирании, которая замедляет деятельность компании, незави- 
симо от того, на благо или нет. Мы вернемся к вопросу о формализации 
процессов в главе 17. 


Внедрение усовершенствований 


Как тестировщик и как тест-менеджер я часто ощущаю, что изменение вы- 
ходит из-под контроля. Как я отмечал ранее, очень важно сохранить пра- 
вильный баланс. Каким образом можно направить процесс управления 
изменениями в сторону болееудачного баланса, сохранив при этом доста- 
точную гибкость процесса? 


1. Максимально объективно с токи зрения компании проанализируй- 
те затраты и прибыли, риски и возможности, присущие имеющему- 
ся процессу управления изменениями. С точки зрения тестирова- 
ния естественно, что в первую очередь обращают внимание на 
риски". Насамом деле, с точки зрения непосредственных исполни- 
телей, любой проект обычно можно сделать проще, допуская мини- 
мум изменений (естественно, исходящих извне проекта), пока про- 
ект находится в процессе разработки. Однако это редко является 
правильным направлением деиствии. 


2. Если затраты и риски перевешивают прибыли и возможности, рас- 
смотрите способы изменения процесса, чтобы снизить затраты 
и риски, как можно меньше наступая на прибыли и возможности. 
Как правило, наблюдается тенденция энергичной реакции на не- 
управляемые и недостаточно управляемые изменения в проекте, 
но учет динамики плюсов и минусов между теми, чьи интересы свя- 
заны с более слабым управлением изменениями, и теми, чьи инте- 
ресы связаны с более плотным управлением изменениями, не име- 
ет ничего общего с улучшением процесса. 


3. Если существует позитивный и актуальный бизнес-план улучшения 
процесса, задайте вопросы себе как тестировщику или тест- 
менеджеру: “Являетесь ли вы подходящей фигурой для защиты из- 
менения? Подходящее ли сейчас время для внесения изменения?” 
Если ответы на оба вопроса отрицательные, найдите человека, ко- 


1 Методы определения затрат и рисков, относящихся к изменениям в проекте, изложены 
в главе 6 книги “ Мапаріпр їйе Тезійти Ртосеѕѕ, Ѕесопі Едїйоп". 
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торый с наибольшей вероятностью добъется успеха, и убедите его 
в этом. Если текущий момент не является подходящим, например, 
до завершения проекта осталось две недели и любое изменение 
должно быть просто заблокировано, лучше подождать, а не ини- 
циировать сеющие распри эмоциональные обсуждения того, что 
является совершенно посторонним для приоритетов бизнеса в на- 
стоящий момент. 


4. Учитывайте политические соображения. Любые изменения процес- 
сов являются политическими. Есть сторонники изменений, и есть 
сторонники сохранения статус-кво. В случае с управлением измене- 
ниями различия могут быть полными. Чем менее функционален те- 
кущий процесс управления изменениями, тем более заметны разли- 
чия между двумя противостоящими сторонами. Какими методами 
вы сумеете преодолеть возражения сторонников статус-кво? 


Последнее замечание возвращает нас к более общей картине. Усовер- 
шенствование процесса должно соответствовать общему представлению 
о ситуации, что становится тем более важным, чем более взаимосвязан- 
ным и взаимопроникающим является сам процесс. В следующей главе мы 
вернемся к большой картине, чтобы посмотреть, как определить хоро- 
ший процесс тестирования, как выстроить такой процесс и как разумным 
способом внедрить усовершенствования в процесс тестирования. 


ГЛАВА 17 


Снова к общей картине: 
совершенствование процесса 
тестирования 


В первой главе мы рассмотрели процесс тестирования в целом, общую 
картину. В последующих главах мы исследовали все ключевые про- 
цессы, составляющие общий процесс. В заключительной главе мы снова 
возвращаемся к процессу тестирования в целом. Для напоминания по- 
звольте мне воспроизвести еще раз Процесс 1 из главы 1. 

Как выявить успешный процесс тестирования? Как справиться с труд- 
ностями? Как перейти от привычного ведения процесса к лучшему спосо- 
бу выполнения работ? 


Определение грамотного процесса тестирования 


На протяжении этой книги мы рассматривали, как работают группа тес- 
тирования и другие группы проекта, когда они следуют грамотно выстро- 
енным процессам тестирования, а также чего они при этом добиваются и 
что приобретают. Что можно сказать о группах, следующих грамотно вы- 
строенному процессу тестирования в целом? 


Предоставление полезных и недорогих услуг 


Многие заинтересованные стороны, включая старших менеджеров и ру- 
ководство компании, безразлично относятся к процессу тестирования 
как к таковому. Их интересует лишь его влияние на затраты и его резуль- 
тат. С позиции стороннего наблюдателя, группа тестирования получает 
ресурсы, использует их для получения важной информации, а затем во- 
время, четко и надежно передает полученные сведения с учетом разнооб- 
разных потребностей заинтересованных сторон. С точки зрения группы 
тестирования, мы предоставляем все эти полезные и недорогие услуги за 
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счет эффективного и производительного тестирования, удовлетворяю- 
щего требованиям сторон, заинтересованных в тестировании‘. 


Процесс 1. Процесс тестирования 


№ этапа Этап Выполнено? 
1. Планирование: понимание места тестирования. а 
А Определить функциональный (система, проект и процесс) а 
и организационный контексты, в рамках которых выполняет- 
ся тестирование. 
1.В Определить и расставить приоритеты рисков качества системы, г 


достичь консенсуса занитересованных сторон проекта относи- 
тельно возможностей тестирования по смягчению этих рисков. 


1.С Оценить временные, ресурсные и финансовые затраты, необ- п 
ходимые для выполнения тестирования и согласованные 
с пунктом 1.В, получить поддержку оценки у руководства. 


1.р Запланировать задачи, зависимости и участников, которые О 
необходимы для смягчения рисков качества системы, и полу- 
чить поддержку плана у заинтересованных сторон проекта. 


2. Подготовка: сбор людей и тестов. п 


2.А Создать команду специалистов-тестировщиков, обладающих а 
соответствующими умениями, навыками, отношением к делу 
и мотивацией, посредством поиска персонала и его обучения. 


2.В Спроектировать, разработать, получить и верифицировать а 
систему тестов, которую группа тестирования будет использо- 
вать для оценки качества системы, предназначенной для тес- 
тирования. 


Проведение: выполнение тестов и сбор результатов. О 


3 

ЗА Получить и установить тестовую версию, состоящую из всех 
или нескольких компонентов системы, предназначенной для 
тестирования. 


о 


3.В Определить, отслеживать и управлять комплектом тестов, с п 
помощью которого планируется проверять каждую из тесто- 
вых версий. 


4. Совершенствование: предоставление информации о проекте 


и его улучшение. 


4.А. Документировать ошибки, обнаруженные в ходе выполнения 
тестов. 


4.В. Обсудить результаты тестирования с ключевыми заинтересо- 
ванными лицами. 


оо оао 


4.С Управлять изменениями и уточнить процесс тестирования. 


и Роберт Сабурин написал прекрасную статью "Аг Үоџг Ѕегуісе”, впервые опубликованную 
в журнале "Зо/їшате Тейтр ати Оицаййу Епріпеетіпр", оїатпе 3, Іѕѕие 3 (Мау/Тип 2001). В настоя- 
щее время ее можно найти на сайтезуу.5йскутіпаз.сот. В этой статье автор рассматривает 
тестирование и работу других групп разработим я проектирования программного обеспече- 
ния как организаций, предоставляющих услуги. 
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Эффективность означает получение желаемого и полезного результа- 
та. В этой книге я делаю упор на четыре способа, при помощи которых 
тестировщики достигают желаемых и полезных результатов. 


1. Обнаружение ошибок, которые будут устранены, или даже предот- 
вращение их внесения. 


2. Обнаружение ошибок, которые не будут устранены, но о которых 
становится известно. 


3. Проведение тестов, которые снижают (потенциально затратные) 
риски. 


4. Обеспечение проекта своевременной, точной и заслуживающей 
доверия информацией. 


Кроме того, эффективность означает, что заинтересованные в тести- 
ровании и в обеспечении качества стороны удовлетворены тем, каким 
образом мы предоставляем результаты. Это вытекает из определения ка- 
чества, данного Джураном: наличие удовлетворенности и отсутствие не- 
удовлетворенности. 

Порой изменения, необходимые для достижения истинной эффектив- 
ности, на самом деле влияют не на сам процесс тестирования, а на то, как 
он воспринимается со стороны. Часто для увеличения степени удовлетво- 
ренности заинтересованных сторон в процессе тестирования нужно до- 
биться реалистичных ожиданий. Применение навыков убеждения и ди- 
пломатии для формирования ожиданий — еще одна полезная услуга, 
которую могут оказать тестировщики. 

Эффективность означает не только достижение желательных резуль- 
татов, но и потребление ресурсов в минимально возможном объеме. 
Имеются в виду не только фиксированные ресурсы (такие как зарплата, 
затраты на инструменты и базисные системы), но и время. Отсрочка в 
завершении проекта ведет к тому, что экономисты называют скрытыми 
издержками. На рынке массового потребления мы теряем возможность 
продажи нашей системы клиентам, готовым за нее заплатить. Работая 
по контракту, мы упускаем возможность вести работы по следующему 
выгодному проекту. Что касается внутренних ІТ-проектов, мы теряем 
шансы своевременно получить преимущества от применения нашей 
системы. 


Проникновение в проект 


Процесс тестирования вовсе не предполагает использование труда не- 
большого количества сотрудников, изолированных в тестовых лаборато- 
риях, в конце проекта. Процесс тестирования состоит из сложных, взаи- 
мозависимых совокупностей видов деятельности. Продуманный процесс 
тестирования включает в себя взаимодействие широкого круга людей на 
протяжении всего проекта. Успешные процессы тестирования пронизы- 
вают весь проект разработки или сопровождения. 


и Всепроникающее тестирование ведется параллельно с другими работами. 
Чем раньше в проекте стартует процесс тестирования, тем более 
полезен он будет для проекта. Обнаруживая дефекты в документах, 
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описывающих требования и архитектуру, мы предотвращаем вне- 
сение ошибок в программу. Мы реалистично оцениваем план про- 
екта, особенно с точки зрения времени и ресурсов, отведенных 
на тестирование. Мы фокусируем внимание и определяем пред- 
стоящие работы за счет тщательного планирования и анализа. 
Мы создаем надежные системы тестов, пригодные к повторному 
использованию. Мы применяем эти системы для обдуманного и 
тщательного выполнения тестов. 


Всєпроникающеє тестирование является совместной деятельностью. 
Группа тестирования в соответствии с процессом тестирования 
оценивает и анализирует материалы, передаваемые другими груп- 
пами. Сотрудники отдела продаж, службы маркетинга, бизнес- 
аналитики и пользователи определяют требования к продукту. 
Группа разработки проектирует и создает систему, подлежащую 
тестированию. Группа управления проектом и руководство компа- 
нии утверждают плановые графики, бюджет и людские ресурсы. 
Часто некоторая внешняя по отношению к группе тестирования 
команда специалистов встраивает компоненты в тестопригодную 
систему. При наличии сложной тестовой среды помощь группе тес- 
тирования в ее установке, конфигурировании и сопровождении 
может оказать группа сетевого и системного администрирования. 
Когда эти группы выполняют договоренности в соответствии с гра- 
фиком и обещаниями, данными группе тестирования, процесс тес- 
тирования протекает гладко. 


Всепфоникающее тестирование требует участия специалистов разного 
профиля. Сотрудники компании, участвующие во всем цикле разра- 
ботки или сопровождения, также выполняют часть задач, входя- 
щих в процесс тестирования. Основные заинтересованные сторо- 
ны участвуют в анализе риска качества. Сотрудники групп 
поддержки заказчиков и операций помогают тестировщикам осво- 
ить реально существующие пользовательские сценарии. Разработ- 
чики проводят адекватное компонентное и модульное тестирова- 
ние. Независимая группа тестирования проводит комплексное и 
системное тестирование системы в целом, охватывающее все ком- 
поненты аппаратного и программного обеспечения. Эти компо- 
ненты могут быть разработаны различными группами данной ком- 
пании или даже сторонними организациями. В ряде случаев бета- 
тестирование, приемо-сдаточные испытания или пилотное тести- 
рование проводят бизнес-аналитики или специалисты, занимаю- 
щиеся изучением рынка сбыта. 


Всепроникающее тестирование “перекрестно опыляет” действия тести- 
рования и разработки. Тестировщики применяют знание предмет- 
ной области приложения, для того чтобы помочь специалистам по 
продажам, маркетингу, бизнес-аналитикам и пользователям опре- 
делить лучшую систему. Используя технические навыки, тестиров- 
щики помогают разработчикам лучше спроектировать систему. 
Тестировщики могут предложить усовершенствования. И тести- 
ровщики, и разработчики занимаются такими компонентами сис- 
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темного тестирования, как заглушки, драйверы, оболочки, генера- 
торы загрузки и автоматизированные скрипты для графического 
интерфейса пользователя. Инструменты тестирования также име- 
ют значение для групп разработки и эксплуатации. Отчеты об 
ошибках и описание обходных путей включаются в базу знаний, не- 
обходимых специалистам по поддержке пользователей. 


ш Всепроникающеє тестирование означает обмен информацией. Группа 
тестирования анализирует результаты каждого из процессов тести- 
рования, кратко формулирует и докладывает о них различным за- 
интересованным сторонам. Руководство применяет результаты 
тестирования в качестве части инструментальной панели руково- 
дителей. 


Для всепроникающего тестирования необходимо соблюдение ряда ус- 
ловий. Заинтересованные стороны должны реалиФтично оценивать, ка- 
кие услуги группа тестирования в состоянии предоставить, и ценить эти 
услуги. Процесс всепроникающего тестирования связан со многими дру- 
гими процессами проекта, эти связи подразумевают четкое распределе- 
ние ролей, ответственности и передачи материалов. И, наконец, общий 
организационный контекст должен поддерживать и подпитывать про- 
цесс тестирования. 

Однажды я работал в небольшой недавно основанной компании. 
Я приступил к работе через месяц после тсго, как было принято реше- 
ние о создании группы тестирования и о выстраивании процесса. Я тес- 
но сотрудничал с маркетологами, программистами и высшим руково- 
дством, чтобы определить грамотный процесс, нацеленный на 
смягчение конкретных рисков качества в условиях финансовых и вре- 
менных ресурсов, которые компания могла себе позволить. Разработчи- 
ки инструментария тестирования совместно с программистами создали 
средства для генерации пользовательской загрузки, которые позволили 
эффективно провести нагрузочное тестирование. Тестировщики со- 
вместно с группой, отвечающей за производительность системы, анали- 
зировали, моделировали и тестировали серверный кластер, настраивая 
работу соответствующей пользовательской загрузки в соответствии с 
прогнозом продаж, предоставленным группой маркетинга. Вместе с ве- 
дущими тестировщиками я принимал участие в совещаниях группы 
управления проектом. Мы готовили и поддерживали в актуальном со- 
стоянии инструментальные панели — основное средство измерения 
хода работ. Руководство, в свою очередь, поддерживало нашу работу. 
Другие непосредственные исполнители — программисты и инженеры 
сборок — трудились с нами плечом к плечу для обеспечения гладкой пе- 
редачи материалов. Процесс тестирования был рациональным и эффек- 
тивным. 

Чем это было обусловлено? Благодарить за это нужно не только тести- 
ровщиков, авсю рабочую группу проекта, включая каждого разработчика, 
менеджера, маркетолога-аналитика и специалиста по поддержке заказчи- 
ка. Каждый, не жалея сил, делал все возможное, чтобы тестирование вне- 
сло существенный вклад в успех проекта. 
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Использование зрелого процесса 


Всепроникающее тестирование часто является (или становится) зрелым. 
Под зрелым процессом я понимаю процесс, к которому применимы сле- 
дующие определения: 


1. Эффективный. Группа тестирования, состоящая из квалифициро- 
ванных специалистов и оснащенная хорошей системой тестирова- 
ния, получает полезную информацию на постоянной основе. 


2. Рациональный. Группа тестирования выполняет каждое задание с 
первого раза и должным образом, поэтому работу не приходится 
переделывать. Группа не тратит время на решение задач, не входя- 
щих в ее обязанности. 


3. Понятный. Тестировщики имеют четкое представление о том, чем 
они занимаются и чем должны заниматься. При этом заинтересо- 
ванные в проведении тестирования и в обеспечении качества сто- 
роны понимают, над чем работает группа тестирования. 


4. Принятый. Тестировщики и заинтересованные стороны пришли к 
согласию по важным вопросам. 


5. Организованный. Каждый тестировщик по отдельности, группа тес- 
тирования в целом, группа тестирования совместно с другими ко- 
мандами работают по определенному распорядку, с четкими пере- 
дачами материалов. 


6. Оптимизирующий. Тестировщики и другие сотрудники компании 
собирают информацию, использующуюся для совершенствования 
процесса тестирования. 


Эти определения взаимосвязаны и подпитывают друг друга. Мы долго 
обсуждали их в данной книге, особенно первые пять. 

Оптимизация также имеет большое значение, особенно в долгосроч- 
ной перспективе. Даже зрелый процесс по причине прогресса со време- 
нем лишается своей зрелости. В области программного и аппаратного 
обеспечения, разработки систем, так же как и в медицине, естественных 
науках и других отраслях высоких технологий, прогресс происходит в по- 
стоянно ускоряющемся темпе. Либо мы будем шагать с ним в ногу, либо 
начнем отставать. 

Приведу пример, не связанный с вычислительной техникой. Процес- 
сы изготовления стали и алюминия дали возможность аэрокосмическим 
технологиям сделать резкий рывок. Братья Райт для испытания первой 
удачной модели самолета втащили его на холмы Китти-Хок, запустили 
двигатель и понаблюдали за происходящим. Сработает ли подобный про- 
цесс тестирования для Конкорда или Боинга 777? Точно так же, по мере 
эволюции технологий, с которыми мы имеем дело, нам, тестировщикам 
систем, необходимо адаптировать и совершенствовать свои инструмен- 
ты, применяемые технологии и процессы. 


Глава 17. Снова к общей картине 497 


Применение подходящего уровня формализации 
и стандартизации 


Чтобы достичь зрелости процесса, некоторые компании применяют 
формальные модели процессов и стандарты. Формализация может озна- 
чать создание формальной модели работы процесса. 

Стандартизация может означать следование установленным отрасле- 
вым стандартам для процессов и документов. В качестве примеров можно 
привести руководство по подготовке документов тестирования Институ- 
та инженеров по электротехнике и электронике (ІЕЕЕ-стандарт 829) 
и требования к разработке документации процесса разработки модели 
зрелости процессов разработки программного обеспечения Института 
программной инженерии (боймаге Епріпеегіпя Іпоѕіісиќе'ѕ Сарабійсу 
Машгіу Модеї, 5КІ СММ) или Международной организации стандартиза- 
ции (Пицегпабопа! Ѕ‹апаагаѕ Ограпігаціоп, 150)". 

Кроме того, стандартизация может подразумевать использование при 
оценке зрелости процесса тестирования стандартных для отрасли моде- 
лей, таких как: 


ш Совершенствование процесса тестирования (Тезё Ргосеѕѕ трго- 
уетепі) Коомена и Пола 


и Модель зрелости тестопригодности (Тема у Магигіу Моде) 
Гельперина и Хияши 


и Модель развития функциональных возможностей тестирования 
(Тезйор Сарабійсу Магигігу Моде!) Бургесса и Драбика 


" Модель зрелости тестирования Бернштейна, Карлсона и Суванна- 
сарта 


В некоторых случаях формальные модели процессов, стандартные 
стратегии тестирования и шаблоны документации образуют хорошие 
стандартные блоки для успешных проектов тестирования. Роджер Дра- 
бик создал модель высокой степени формализации для всего процесса 
тестирования: с самого начала и до послепроектного анализа и совершен- 
ствования. Данная модель, минимальная детализация которой представ- 
лена на рис. 17.1, прибегает к диаграммам “ввод- обработка-вывод” для оп- 
ределения всех “существенных элементов формальной программы 
тестирования проекта среднего (более 20 000 исходных строк кода) или 
крупного (свыше 100 000 срок кода) масштаба”. Драбик не определяет ни- 
каких конкретных стандартов документации, но упоминает, что стандар- 
ты ІЕЕЕ 829 вполне пригодны”. 


1 Для получения более полной информации о данных стандартах см. “ІЕЕЕ Зойишате 
Епұіпегтіпр Зіапаатаз СоЦесйот, 1997 Еаййоп", Раџк м др. “Тһе Сарафййу Маитиу Модеї и 
Зсвтаисі “150 9000 бог Зоймаге Оеуе]орег5”. 


Более полную информацию, касающуюся методологии совершенствования процесса 
тестирования, см. в книге Коомена и Пола “Тез Росез5 Їтртооетепі". Краткий обзор и ене 
ние этих моделей зрелости см. в статье Драбика "Стомлі ої Масигіїуіп ће Тезірр Ргосеѕѕ” н 
сайте мум.зойгсеѕс.огр / агісієв /гагаһіск3.һ. 


Более подробную информацию о полной модели Драбика вы можете найти в его книге 
“ Веѕі Ртасіісеѕ јот Ѕоўїшате Теѕіпо’ и на чуми .50Й Тез. огу / 5ір5 / платегіа! /гагађіск1. Ы. 
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аемы и двумя ведущими ан ры я неп 
ентами. ии было мало, процесс о 


‘стремилась к сия потребностей внутренних заказчиков из 
всех рабочих групп проекта, ЕВ присегали. кве успугем, оказалось. 
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-наковом уровне зрелости процессов! 


Другой формальный процесс тестирования описан в книге Рика Крэй- 
га и Стефана Яскиля "5узієтаг іс боПшате Тейт”. На рис. 17.2 приведена диа- 
грамма этого процесса с минимальной детализацией. Подобно модели 
Драбика, она охватывает диапазон от первичного знакомства с вопросом 
до анализа, следующего за выпуском версии. По ходу дела тестирование в 
ней разбивается на следующие составляющие: 


ш Уровни, обычно модульное тестирование, комплексное тестирова- 
ние, системное тестирование и приемо-сдаточные испытания (ка- 
ждый из них представлен на рис. 17.2 как “Уровень |") 


и Фазы в рамках каждого уровня (например, планирование, получе- 
ние и измерение) 


и Действия, выполняемые на этих фазах (например, анализ, проек- 
тирование, реализация) 


и Задачи, рые Срна исполнителями дин ВЫПОЛ- 
нения действий і 
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Реализация ‚процедуры ' 
Праблемм >| Создание плана спровктированных | - 92 


тестирования ето 
34 


Планы зані 
Запросы на изменения 


Обновленив 
тестовой 
документации | 4 


Рис. 17.1. Уровень 1 модели процесса тестирования “ввод-обработка-вывод” 
по Драбику (Соругідпі с 1995 Бу Воддег Огабіск. 
Приводится с разрешения автора.) 


В данном процессе тестовая документация ведется по стандарту 
ТЕЕЕ 829'. 

Применение формальных моделей в тестировании влияет не только 
на подход к проведению тестирования и'єго документирования, но и на 
способ передачи результатов тестирования. Иногда мы мимоходом рас- 
сказываем о результатах тестирования, обсуждая их с заинтересованны- 
ми сторонами и внутренними заказчиками по электронной почте, остав- 
ляя сообщение на автоответчике, в телефонных разговорах один на один 
и на телеконференциях, останавливаясь поговорить при встречах в кори- 
доре или на проектных совещаниях. При использовании других подходов 
мы сообщаем о полученных результатах в более структурированной фор- 
ме, прибегая к письменным отчетам, количественному анализу, графи- 
кам, таблицам, измерениям, формальным моделям и структурированным 
документам. Внедрение формальных методов работы может поставить 
группу тестирования перед необходимостью более частого предоставле- 
ния результатов в структурированном виде. 

Чтобы принять решение об организации формализованных методов 
работы и о стандартизации, следует оценить все плюсы и минусы. С од- 
ной стороны, есть значительные потенциальные преимущества. Форма- 


1 см. книгу Крэйга и Яскиля “буяетайс бойшате Тейт”. В книге Майкла Шмидта (Місраєї 


Ѕсһтіаг) “Ипретепипр йе ГЕЕЕ 5о/имте Епріпеепіпе Затаата" описан полный процесс создания 
и сопровождения программного обеспечения, дополненный обширным подмножеством 
стандартов ІЕЕЕ. 
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Тестирование проекта 


УРОВНИ 


Рис. 17.2. 


Этапы архитектуры 50Е (Соругідћї с 200 Ѕоймаге биаШу Епдіпеегіпо, 
мс. Приводится с разрешения.) 


лизация и стандартизапия процесса тестирования позволяют тестиров- 
щикам и тест-менеджерам: 


Снизить беспорядочность и непредсказуемость работ по тестиро- 
ванию. 


Обеспечить быстрое, систематическое обучение новых сотрудни- 
ков группы тестирования; в некоторых случаях это позволит но- 
вичкам в тестировании выполнять те работы, которые в против- 
ном случае легли бы на плечи квалифицированного тестировщика. 


Создать и оптимизировать шаблоны и компоненты системного тес- 
тирования, пригодные для повторного использования. 


Обеспечить твердую основу для непрерывного совершенствования 
процесса. 


Прояснить предварительные условия, входные данные, зависимо- 
сти и выходные данные, необходимые для эффективного и резуль- 
тативного тестирования. 


Подготовить документацию, которая может выступать в качестве 


юридического доказательства, что тестирование проводилось со- 
гласно общепринятой практике. 


С точки зрения получения и передачи информации, принятие стан- 
дартов и формализация процесса могут: 


Создать полный и непротиворечивый архив данных по проектам 
для оценки затрат последующих проектов. 
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и Создать общепринятые формы для отчетов о результатах тестиро- 
вания, позволяющиє всей рабочей группе проекта и даже компа- 
нии в целом общаться на одном языке. 


= Снизить риск того, что не будет собрана информация, которая яв- 
ляется критичной для тестирования. 


Еще одним преимуществом для некоторых групп тестирования явля- 
ется соответствие определенным стандартам. В ряде случаев при разра- 
ботке системы служба внутреннего контроля, заказчики, правительствен- 
ные или другие полномочные органы устанавливают определенный 
стиль ведения документации и модель процесса, которые не подлежат об- 
суждению. Для того чтобы получить разрешение на выпуск или поставку 
системы, рабочая группа проекта должна следовать определенным пра- 
вилам. Например, компании, продающие медицинские системы в США, 
должны работать в соответствии с положениями Федерального Управле- 
ния по контролю над продуктами и лекарствами правительства США. 
Иногда предприятия, приобретающие системы или компоненты систем, 
накладывают на своих поставщиков определенные требования, что при- 
водит кформализации или стандартизации процесса тестирования. При- 
веду два примера: чтобы иметь возможность заключать оборонные кон- 
тракты с армией США, компания должна достичь уровня зрелости, 
оцениваемого по модели развития функциональных возможностей 
(СММ), тогда как многие крупные компании, приобретающие компьюте- 
ры на базе Іпѓе], настаивают на сертификации по стандартам М!сгозой. Й, 
наконец, в некоторых случаях стремление к соответствию определенным 
стандартам диктуется скорее желанием получить преимущества на рын- 
ке, нежели соображениями соответствия. Например, оффиюрные компа- 
нии получают сертификат СММ или 150 9000, чтобы потенциальные за- 
казчики могли быть уверены в качестве предлагаемых услуг. 

С другой стороны, существуют серьезные подводные камни, связан- 
ные с переходом к работе по стандартам и формальным процессам. Во- 
первых, экстенсивная формализация и стандартизация, как правило, тре- 
буют больших финансовых вложений. Время, проведенное в обсуждении 
шаблонов, разработке формальных моделей процессов тестирования, ис- 
следовании и применении стандартов, спорах по поводу темпов преобра- 
зования и подходов к изменению процесса и т.п. — это время, не исполь- 
зуемое на собственно тестирование. В некоторых случаях подобные 
инвестиции могут со временем окупиться, но для многих компаний в рам- 
ках одного проекта подобные непроизводительные расходы просто недо- 
пустимы. Несложные методики, например использование списков кон- 
трольных вопросов, в состоянии помочь снизить затраты. 

Помимо первоначальных затрат, слишком жесткая стандартизация или 
формализация может снизить производительность. Люди порой слепо 
следуют процессам, и в результате работа ведется непродуктивным или 
даже антипродуктивным образом. Тестировщики могут тратить много вре- 
мени на заполнение пустых строк в шаблонах документов, не задаваясь во- 
просом: каким образом документирование сведений способствует лучшему 
проведению тестирования? Часто рассказывают притчу о сыне, который 
спрашивает свою мать, почему она всегда отрезает часть от куска свинины, 
прежде чем начать ее готовить. Мама отвечает: “Не знаю, так меня научила 
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твоя бабушка”. Сын спрашивает у бабушки, и та ему рассказывает: “О, когда 
твоя мама была маленькой, у нас не было такой большой жаровни, чтобы 
зажарить все мясо целиком, вот мне и приходилось отрезать кусочек, что- 
бы оно поместилось”. Необходимо иметь гибкость и знать, как выявлять 
исключения из правил и обходиться с ними. 

Особенно важны гибкость и продуманный подход в случае, если вы адап- 
тируете под свои нужды модели процессов, стандарты и шаблоны, создан- 
ные другими людьми. У разных людей разный стиль работы, и эти различ- 
ные подходы незаметно влияют на процессы и стандарты. В хорошо 
работающих компаниях, например в тех, что уже применяют зрелые про- 
цессы на протяжении всего жизненного цикла системы, можно ожидать ми- 
нимальных усилий при обращении к стандартному процессу тестирования, 
совместимому с уже имеющимся процессом разработки. Однако я несколько 
раз работал в таких компаниях, где попытка одним махом внедрить фор- 
мальные методы и стандартную документацию привела бы к полной неспо- 
собности тестировщиков приносить какую-либо пользу. Изучая методы, ис- 
пользуемые другими, основательно обдумайте допущения и предпосылки. 

Поступая подобным образом, вы, кроме того, морально подготови- 
тесь к наиболее разрушительной опасности на пути эффективного вне- 
дрения моделей формальных процессов, стандартов или вообще любых 
усилий по совершенствованию процесса: эффекта серебряной пули. Не- 
которые полагают, что шаблоны и функциональные схемы решают все 
проблемы, связанные с тестированием. Например, в ходе написания 
этой главы я получил кое-какую литературу по маркетингу от одной ком- 
пании, занимающейся консалтингом и обучением, с описанием их про- 
цесса тестирования. Процесс представлял собой патентованную смесь 
модели ЗЕ! СММ и процессов и шаблонов ТЕЕЕ. Они утверждали, что если 
тестировщики будут следовать их формальному подходу, то действия тес- 
тирования будут удовлетворять потребности любого проекта по разра- 
ботке программного обеспечения или превосходить эти нужды. 

Подобные заявления и подобный образ мысли опасны. 

Можно усовершенствовать существующий процесс тестирования, изу- 
чив имеющиеся ключевые процессы тестирования и среду, в которой 
происходит работа. Можно разумно применять идеи из этой или другой 
книги, статей и документов. Формализация и стандартизация в состоя- 
нии принести значительную выгоду, уровень же усилий и объем докумен- 
тации при этом часто бывает вполне приемлемым. 

Однако единственно верного процесса не существует. Вы не должны 
непременно применять громоздкие диаграммы “ввод-обработка-вывод” 
или делать отчеты, совместимые со стандартом ІЕЕЕ 829. Возможно, бу- 
дет достаточно всего лишь составления простых списков контрольных 
вопросов для каждого ключевого процесса и приведения к единообразно- 
му виду измерений, графиков и отчетов всех тестировщиков компании. 
Поступайте так, как в вашей ситуации представляется разумным. 


Использование подходящих стратегий 


В этой книге я пропагандирую стратегию тестирования, основанную на 
рисках, и описываю, как я ее использую. Некоторые тестировщики счита- 
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ют, что системные тесты должны строиться исключительно на специфи- 
кациях требований и архитектуры, а сами спецификации должны одно- 
значно отвечать на любой вопрос по поводу корректности поведения 
системы. Документы с описанием требований и архитектуры и, конечно, 
тестовые сценарии являются полезными моделями того, как должна ра- 
ботать система. Однако в конечном счете это всего лишь модели - - полез- 
ные, но упрощенные. Поэтому не будем заставлять себя и своих тестиров- 
щиков ограничиваться этими моделями и строго следовать им. 

В главе 15 упоминалось, что разработка или сопровождение проекта 
имеет успех, когда соединяются четыре составляющие: 


ш Свойства. Создаем ли мы необходимое множество функций, кото- 
рые решают проблемы пользователей и заказчиков? 


м Сроки, Можем ли мы передать в заданные сроки систему, решаю- 
щую эти проблемы. 


= Бюджет. Можем ли мы передать систему способом, который явля- 
ется привлекательным с финансовой точки зрения для заказчиков, 
пользователей, спонсоров проекта и создателей системы? 


= Качество. Можем ли мы передать свойства в состоянии, которое 
подходит для применения пользователями и заказчиками? 


Если вы можете утвердительно ответить на все четыре вопроса, про- 
ект будет успешным. 

На самом же деле мы узнаем ответы на эти вопросы только после того, 
как по окончании проекта пройдет некоторое время. До или в ходе проек- 
та мы можем говорить лишь об уровне уверенности или вероятности ус- 
пеха. Другими словами, на протяжении всего жизненного цикла проекта 
мы рискуем тем, насколько успешным он окажется. Потому мудрые менед- 
жеры проекта применяют управление рисками. 

Тестирование является частью разумной стратегии по управлению 
рисками проекта. На протяжении этой книги я делал акцент на способах 
увязывания тестирования с рисками и со снижением рисков. Были пока- 
заны различные инструменты и методики предоставления услуг и инфор- 
мации, призванные помогать рабочей группе проекта в управлении рис- 
ками, связанными с качеством системы. 

Не все прибегают к стратегии, основанной на рисках. Ниже приводит- 
ся краткий список некоторых других стратегий тестирования. 


и Исчерпьвающая. Тестируйте все, как можно полнее. 


= Вынужденная. Тестируйте что угодно и где угодно; распределяйте 
работы по тестированию на весь продукт. 


и Охота за ошибками. Используйте профили, систематизацию оши- 
бок и интуицию, чтобы нацеливать тестирование на те места, где 
водятся ошибки. 


м Список контрольних вопросов. При тестировании руководствуйтесь 
списками контрольных вопросов, созданными в течение опреде- 
ленного времени. 


и Управляємая программистами. Тестируйте согласно указаниям про- 
граммистов и рассматривайте их как высший авторитет на предмет 
правильных действий. 
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и Управляємая заказчиками или пользователями. Тестируйте в соответ- 
ствии с тем, что, по мнению людей, оплачивающих систему, или 
экспертов в данной отрасли, которые будут использовать систему, 
нуждается в тестировании. 


и Управляемая реализацией. Изучайте архитектуру, код, схемы системы 
ит.п., чтобы определить, на чем сконцентрировать внимание при 
тестировании. 


и Аналитическая. Соберите всю имеющуюся информацию, изучите 
структуру системы, установки и цели; проводите тестирование на 
основе этих обширных и глубоких знаний. 


и Интуитивная. Тестируйте в соответствии с тем, что говорят кол- 
лективный опыт, мудрость и интуиция сотрудников группы тести- 
рования на предмет того, что следует тестировать. 


ш Исследовательская. Одновременно изучайте систему, тестируйте, на- 
ходите ошибки и совершенствуйте подход ктестированию, коррек- 
тируйте его направленность. 


= Быстрая. Тестируйте, применяя облегченные процессы, в поиске 
вероятных ошибок ориентируйтесь на готовность реагировать на 
недавно внесенные изменения. 


Функциональная. Тестируйте каждую функцию системы по очереди. 


Основанная на требованиях или претензиях. Тестируйте каждое требо- 
вание или претензию к продукту. 


во Автоматизированная регрессия. Тестируйте, применяя исключитель- 
но автоматизированные тесты, которые можно повторить при не- 
обходимости проверки на наличие регрессии. 


= На основе состояний системы. Тестируйте различные состояния и пе- 
реходы из одного состояния в другое, которые могут иметь место. 


и На основе сценариев использования системы. Тестируйте в соответст- 
вии с различными возможными в реальной жизни сценариями по 
всем областям функциональности системы. 


ш На основе областей системы. Анализируйте различные области вход- 
ных ивыходных данных и обработки данных, которые есть в систе- 
ме, проверяйте наиболее репрезентативных представителей каж- 
дой области. 


и Массовая случайная. Тестируйте огромное количество совокупно- 
стей данных, выбранных случайным образом, при помощи автома- 
тизированных инструментов. 


я На основе качества. Тестируйте, ориентируясь на важные свойства 
системы, такие как функциональность, удобство и простота ис- 
пользования, надежность, производительность, масштабируе- 
мость и Т.Д. 


Зтот список появился в результате онлайнового обсуждения вопроса с Россом Коллар- 
дом, Семом Канером, Кэти Айберли и Камешем Пеммараджу. Благодарю их за содействие. 
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Возможно, вы заметили, что многие из этих стратегий были показаны 
в представленных мной процессах. Несмотря на то, что основная движу- 
щая сила моего подхода к тестированию основана на рисках, все другие 
стратегии являются полезными инструментами, применяемыми по мере 
необходимости. Кроме того, невзирая на то, что подход к работе, осно- 
ванный на рисках, во многих случаях эффективен, вам следует продумать, 
не будет ли другая стратегия более подходящей в ваших условиях. 


Успешное внедрение инструментов 


Разработка инструментов тестирования — бурно растущий бизнес, од- 
нако часто попытки внедрить их оказываются неудачными. Почему? Ци- 
тирую высказывание Фьюстера и Грэм: “Автоматизация неразберихи все- 
го лишь быстрее приведет вас к неразберихе”. Наличие основательного, 
повторяємого, хорошо понятного процесса становится залогом успеха 
использования инструментов автоматизированного тестирования. 

Это особенно важно по мере нарастания сложности проекта. На 
рис. 17.3 показано, каким образом в проектах с низким уровнем сложности 
квалифицированные инженеры (включая тестировщиков) при помощи 
верно выбранных методов могут самостоятельно справиться с трудностя- 
ми проекта и “пробить проекту дорогу”, чтобы предоставить систему поль- 
зователям и заказчикам. На рис. 17.4 показано, что по мере нарастания 
сложности необходимо поддерживать “мост” между пользователями и ра- 
бочей группой проекта, чтобы предотвратить его обрушение под давлени- 
ем, оказываемым на него проектом, и этой поддержкой начинает зани- 
маться процесс. И, наконец, из рис. 17.5 видно, что мы можем укрепить 
процесс разработки, сопровождения или приобретения, в том числе про- 


`Квалифицированная Пользователи аа 
рабочая группа проекта и заказчики Система 


Технология 


Рис. 17.3. Навыки и методы возводят мост в простых проектах 


1 ом, книгу Марка Фьюстера и Дороти Грэм “Автоматизация тестирования программного 
обеспечения". 
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Концепция 


Ивалифицированная 
с рабочая группа проекта 


Пользователи 


и заказчики Система 


Рис. 17.4. По мере нарастания сложности процесс должен усиливать 
навыки и методы 


Процесс Процесс 


( Концепция 


Пользователи 


и заказчики Система 


Рис. 17.5. Грамотный процесс поддерживает успешное внедрение 
инструмента 


цесс тестирования, инструментами, чтобы справиться с большими трудно- 
стями в очень сложных гроектах. Разумное сочетание квалифицирован- 
ных и увлеченных работников, использования передовой, но устойчивой 
технологии, повторяемых и понятных процессов и должным образом при- 
меняемых инструментов позволит нам довести сложные проекты до ус- 
пешного завершения. 


Получайте удовольствие от вдохновения 
и от возможности непрерывно учиться 


Один из этапов процесса роста команды, обсуждаемых в книге, включает 
в себя программу повышения квалификации, подразумевающую обуче- 
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ние и последующее применение изученных знаний в выполнении задач 
тестирования. В нашем примере Лин Цу должна была участвовать в кон- 
ференции, изучатьуправление документацией и затем на основе получен- 
ных знаний разработать несколько тестов. Это одна из форм обучения: 
начать что-то делать, приобрести некоторые новые навыки и закрепить 
полученные знания, применив их. 

Кроме того, мы можем осваивать новое, изучая то, что сделано други- 
ми. Инспекции, рецензирование документации, кода и тестов являются 
не только методами контроля качества, но также дают их участникам от- 
личную возможность узнать что-то новое. Программирование и тестиро- 
вание, проводимое совместно двумя сотрудниками, находящееся пока на. 
стадии эксперимента, столь же многообещающе в плане обучения напар- 
ников друг друга. 

Когда мы учимся делать что-то самостоятельно, это еще одна форма 
обучения. Отец научил меня игре в шахматы, играя вместе со мной. Так 
же я научился кататься на велосипеде. Я не изучал теорию шахматной 
игры или езды на велосипеде. Я не пытался понять, как другие играют в 
шахматы или катаются. Я просто начал играть в шахматы и ездить на ве- 
лосипеде, удачи и поражения помогли мне в учебе. 

Порой нам в голову приходят удачные идеи. Однажды, работая над 
системой автоматизированных тестов, я пытался выбрать верный син- 
таксис для набора тестов и для определения тестовых сценариев. В это же 
время я готовил документ в формате НТМІ Этот документ не относился 
к проекту. Он просто входил незначительным пунктом в список того “что 
нужно сделать”, и я занимался этими вопросами, ожидая, пока в голову 
придет хорошее решение главной проблемы. И, конечно, когда я взгля- 
нул на тэги (например, «Б» и </Ъ> - начало и окончание полужирного 
шрифта) в файле НТМІ, я понял, что могу использовать подобные метки. 
Так, я выбрал <АсИоп> и < /Асіор> для того, чтобы отметить начало и ко- 
нец фрагмента, показывающего инструменту тестирования его часть дей- 
ствия в тестовом сценарии. Такие моменты открытий иногда происхо- 
дят, когда мы отвлекаемся от поиска решения своей проблемы, как 
в случае с Архимедом, пожелавшим принять ванну. 

Обучение может быть беспорядочным. Обучением иногда трудно 
управлять. Но оно всегда в радость. Что еще важнее, оно побуждает к дей- 
ствию. Как часто, проводя собеседования, я слышал вариации на тему 
“чего я больше всего хочу от этой работы, так это возможности продол- 
жать узнавать что-то новое”. Люди с мотивацией и жаждой знаний лучше 
работают. Более того, с каждым днем их труд становится изящнее и эф- 
фективнее. Поэтому в роли менеджера я способствую обучению и поощ- 
ряю творческое начало. Я поощряю вдохновение. Я работаю над тем, что- 
бы сделать обучение, творческий подход и вдохновение — и неизбежные 
ошибки, которые с этим связаны, — безопасными. Я выяснил, что резуль- 
татом является приносящая положительные эмоции, мотивирующая 
и продуктивная среда для работы 
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Решение проблем 


Мы рассмотрели ряд сложных проблем, возникающих в конкретных про- 
цессах тестирования. Общий процесс тестирования также сопровожда- 
ется многочисленными проблемами". 


Как измерить то, чему мы не в силах дать определение? 


Вернемся к определению качества, которое я позаимствовал у Джурана: 
наличие поведения, удовлетворяющего пользователя, и отсутствие пове- 
дения, не удовлетворяющего пользователя. Используя это определение, 
нам, возможно, следовало бы измерить ряд полезных свойств и ряд оши- 
бок, найденных пользователями. Может быть, эти два показателя измеря- 
ют качество? Я отношусь к этому скептически по двум причинам. 

Во-первых, для качества системы в равной степени важно, какие ошиб- 
ки остались и сколько их осталось. Знаем ли мы о качестве все необходи- 
мое, если единственное, что нам известно, — это то, что кмоменту переда- 
чи продукта мы устранили 90% ошибок? Уверены ли мы, что система 
удовлетворит потребности 90% пользователей и заказчиков? Может 
быть и так, если все оставшиеся дефекты влияют на одних и тех же поль- 
зователей и заказчиков и их 10% от общего числа. Но предположим, чтоу 
нас имеется один дефект, оказывающий воздействие на 20% заказчиков. 
Подобные рассуждения превращают результаты измерения ряда полез- 
ных характеристик в далекие от совершенства и неполные показатели. 
Поэтому, хотя эти цифры могут быть параметрами в некоторых уравне- 
ниях качества (очевидно, предпочтительнее иметь больше полезных 
свойств и меньше ошибок), они не являются единственными и не могут 
выступать в роли двух основных параметров. 

Второе возражение основано на том, что не все согласны с определе- 
нием Джурана. Журнал “ОпаШу Ргоргеѕѕ”, принадлежащий Атегісап 
Ѕосіегу ої Оцаїу, опубликовал статью Роберта Хойера и Бруки Хойер под 
названием "Что такое качество?”. В ней рассматривались восемь различ- 
ных определений, которые дали восемь гуру в области качества. Приведу 
некоторые из определений, упомянутые в этой статье: 


и Фил Кросби: “Соответствие требованиям”. 


и У. Э. Деминг: “Качество [существует] в группах посредника [заин- 
тересованного лица] ...” 


и Геничи Тагучи: Качество — это “потеря... [нанесенная] обществу” 
продуктом или системой. 


Р. Хойер и Б. Хойер делят эти разнообразные определения на две груп- 
пы. Определения, отнесенные ими куровню 1, провозглашают, что каче- 
ство — это предоставление продуктов и услуг, “измеримые характеристи- 
ки которых удовлетворяют фиксированному набору [численно] 


Трудности, связанные с общим процессом тестирования, удачно отражены в книге Бил- 
ла Пэрри (ВШ Репу) и Рэнди Райса (Капду Вісе) “биплита Ше Тор Теп Срайепрез оў Зойшате 
Тейт”. - 
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определенных спецификаций.” Определения уровня 2 характеризуют ка- 
чество как “независимое от ... измеряемых свойств” и берущее начало в 
“[удовлетворенных] ожиданиях заказчика”. 

Если мы выбираем подход уровня 1, мы можем измерить характери- 
стики и затем разработать показатели качества, таблицы или модель, ос- 
нованные на этих измерениях. Эти показатели, таблицы или модель мо- 
гут быть неточными и неопределенными, однако, возможно, окажутся 
полезными в качестве ориентира. 

Если мы соглашаемся с подходом уровня 2, то можем допустить, что 
подобные измерения вредят достижению основной цели обеспечения ка- 
чества — удовлетворению пользователей и заказчиков. Выбор данного 
подхода не означает, что мы должны прекратить измерение качества. Он 
означает, что мы должны тестировать эти показатели на предмет соот- 
ветствия стандартам удовлетворенности заказчика и пользователя. 


Незрелые процессы разработки и сопровождения 


Ранее я рассматривал проникновение процесса в проект и его зрелость как 
взаимосвязанные свойства успешного процесса тестирования. Успешный 
процесс тестирования действительно будет охватывать весь проект, однако 
обратите внимание, что проект всегда проникает в процесс тестирования. 
Когда проект в целом ведется вусловиях недостаточной зрелости процесса, 
процесс тестирования становится беспорядочным и непредсказуемым, с по- 
ниженной эффективностью и производительностью. 

Я люблю самостоятельно оценивать проект, пользуясь моделью СММ. 
После изучения ключевых областей процесса вам, возможно, потребует- 
ся не более часа, чтобы понять, ведется ли процесс на Первоначальном, 
Повторяємом, Описанном, Управляемом или Оптимизирующем уровне. 
(Будьте тактичны в применении сведений, полученных вами таким обра- 
зом.) Низкий уровень зрелости проекта часто указывает на то, что с про- 
цессом тестирования будут сложности. 

Тестировщики, работающие в проектах с низким уровнем зрелости 
процессов, сталкиваются с конкретным риском, связанным с восприятием 
качества, а значит, и усилий, потраченных на его оценку и обеспечение, 
как предмета роскоши. Компании не могут создавать программы без про- 
граммистов, работать с сетью без операторов сети, выпускать продукт без 
инженеров сборок или оказывать помощь без сотрудников службы техни- 
ческой поддержки, но компании могут (а некоторые так и делают) прода- 
вать и использовать системы, не тестируя их. В тяжелые времена именно 
от предметов роскоши отказываются в первую очередь. По мнению авто- 
ров "ТРе Сара у Маштиу МойеГ, в незрелых компаниях “плохо понимают, 
каким образом конкретные этапы процесса создания программного обес- 
печения влияют на качество, и качество продукта трудно прогнозировать. 
Более того, виды деятельности, нацеленные на повышение качества, та- 
кие как рецензирование и тестирование, часто сокращаются или исключа- 
ются, когда проект выпадает из запланированного графика”. 


К.М.Ноуег апа Вгооке Ноуєг “УЋаї 15 ОпаШу?”, Оша у Ргортеѕѕ, у 2001. 
МагК Раш К и др. “ТЁе Сарай у Маитёу Моде!", с. 7. 
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Неэффективность работы, являющаяся следствием низкой зрелости 
проекта, в сочетании с восприятием со стороны руководства тестирова- 
ния как излишества делает проекты с низким уровнем зрелости опасны- 
ми для тестировщиков. В таких случаях больше говорите с вашими и дру- 
гими менеджерами об их взглядах на тестирование и ожиданиях от его 
проведения, и обратите внимание на признаки колебаний, когда дела 
пойдут неважно. 

Зная, какое влияние могут оказать незрелые процессы разработки на 
группу тестирования, квалифицированные тестировщики порой пытают- 
ся руководить совершенствованием процесса разработки. Это опасно. 
Скорейший и наиболее эффективный из известных мне способов поте- 
рять уважение и сжечь политический капитал — стать назойливым тести- 
ровщиком, который бегает по компании и указывает другим, как им делать 
свое дело. Если к подразделению, отвечающему за тестирование, не отно- 
сятся как к первой скрипке, то вы будете выглядеть ханжой, которому не 
следует совать нос не в свое дело. Если тестирование в компании представ- 
ляет собой хорошо отлаженный механизм, то вас, вероятно, будут считать 
надоедливым всезнайкой. Если вы чувствуете, что необходимо изменить 
процесс в рамках всей компании, возможно, вы сумеете найти единомыш- 
ленников на уровне топ-менеджеров, которые возглавят это дело. 


Нереалистичные ожидания 


Даже в компаниях с высоким уровнем зрелости часто имеется неверное 
представление о тестировании. Поговорив со своими менеджерами о 
том, что они ожидают от тестирования, вы, возможно, выясните, что в ва- 
щей компании тоже отсутствует верное понимание тестирования. В запу- 
щенных случаях менеджеры полагают, что тестирование представляет 
собой распыление на систему некоего волшебного порошка качества, 
с помощью которого можно избавиться от ошибок (подобно пестицидам, 
уничтожающим тлю). 

Я знаком с одним тест-менеджером, получившим плохую оценку по ре- 
зультатам ежегодной аттестации и лишенным премии, поскольку его ком- 
пания выпустила полный ошибок продукт. В свое время он докладывал о 
наличии большинства этих ошибок, они были отражены в базе дефектов, 
но ему отвечали, что эти ошибки не существенны. Вскоре после этого он 
успешно нашел новую работу, где люди охотно расставались со своими не- 
реалистичными ожиданиями по поводу тестирования. Менеджер одного 
из проектов, которым я занимался, рассчитывал, что мы найдем все 
ошибки за один раунд тестирования, затем программисты за несколько 
дней устранят их, и следующий раунд тестирования подтвердит, что все 
найденные ошибки устранены, и не вьтярит новых. 

Нереалистичные ожидания могут принимать много форм. Одно из 
распространенных обличий нереалистичных ожиданий связано с тем, 
что тестирование воспринимается как в некотором роде тривиальная за- 
дача. Работая над этой книгой, я получил предложение внедрить в компа- 
нии процесс тестирования, включая полностью автоматизированное рег- 
рессионное тестирование. Я ответил, что вместе со своими ассистентами 
справлюсь с этой задачей. Тогда они добавили, что хотят, чтобы эту рабо- 
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ту провел одни тестировщик средней квалификации за шесть недель. Ко- 
гда же я ответил, что мы, возможно, сумеем провести грамотный анализ 
рисков, дать реалистичную оценку положения дел и составить продуман- 
ный план действий в два раза быстрее, но внедрение займет месяцы рабо- 
ты, они решили обратиться к кому-нибудь другому. 

Целое семейство нереалистичных ожиданий обуславливается невер- 
ным представлением, что тестирование должно быть в состоянии полу- 
чить полное покрытие при использовании минимальных ресурсов. Я, на- 
пример, не знаю, как выявить проблемы производительности иначе, чем 
провести тестирование в среде, аналогичной среде пользователя, что 
иногда дорого обходится. Если компания считает, что не стоит так тра- 
титься на то, чтобы заранее узнать об ошибках производительности, ей 
не следует проводить подобное тестирование. Однако менеджерам, при- 
нимающим это решение, следует понимать, что они согласились наувели- 
чение риска качества за счет снижения риска не уложиться в рамки бюд- 
жета, и что, возможно, придется жалеть о таком компромиссе. 

Другое нереалистичное ожидание в отношении группы тестирования, 
с которым я сталкивался, заключено в “древней” заповеди руководите- 
лей: “Не говорите мне о проблеме, если не можете предложить, как с ней 
справиться”. Эта тактика может быть разумной применительно к некото- 
рым менеджерам и командам, поскольку она позволяет предотвратить 
бесконечные попытки избежать ответственности. Однако группа тести- 
рования — особенная: мы существуем лишь для того, чтобы предоставлять 
беспристрастную, точную информацию о текущем состоянии качества 
системы. Часто в системе, которую мы тестируем, на самом деле много 
ошибок. Существуют как разумный, так и неразумный способы сообщить 
об этом, однако со стороны менеджеров нереалистично было бы ожидать 
от тестировщиков готового решения по поводу каждой найденной ошиб- 
ки. Это всего лишь еще одна ситуация, где под личиной стремления под- 
держать командный дух скрывается ожидание волшебного порошка каче- 
ства. Если тестировщикам не дают возможности заявлять о проблемах в 
тех случаях, когда им не известны пути устранения этих проблем, проект 
лишается большинства преимуществ наличия в нем независимой группы 
тестирования. 

Часть проблем, связанных с ожиданиями, возникает из-за смешения 
функций тестирования и контроля качества. Настоящая группа по кон- 
тролю качества имеет многообразные обязанности и полномочия, позво- 
ляющие ей добиться того, чтобы процессы разработки и сопровождения 
завершились созданием качественной системы. Группа тестирования 
оценивает качество. Это понятные роли и задачи, однако мне приходи- 
лось сталкиваться с тем, что от группы тестирования ожидали обеспечения 
качества. 

(Если вы настоящий, добросовестный менеджер по контролю качест- 
ва, в ваши обязанности входят процессы, не описанные в этой книге. Кро- 
ме того, процесс подбора персонала будет отличаться от процесса, пред- 
ставленного в главах 8 и 9. И, наконец, сфера вашей компетенции должна 
быть не такой, как у типичного тест-менеджера. Обеспечение качества 
подразумевает понимание всего процесса разработки программного 
обеспечения, углубленные навыки в программировании и другие техни- 
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ческие знания, обучение управлению качеством и знание формальных 
методик по совершенствованию процесса, таких как 150 9000, СММ и то- 
тальное управлениє качеством.) 

Между компанией и группой тестирования должно существовать сво- 
его рода соглащение по поводу того, какие услуги предоставляет группа 
тестирования. Если ваша компания определила это соглашение с помо- 
щью официально сформулированных целей и задач, используйте их. 
Если компания прибегает к управлению в соответствии с целями (тапа- 
ретепеБу-оБесвуе) на уровне тест-менеджеров, значит, ориентируйтесь 
на это. Ваша задача — избежать неверной трактовки вашей роли, особен- 
но со стороны старших менеджеров и руководства компании. 

За годы работы я сталкивался со многими менеджерами проекта, кото- 
рым требовалась помощь в понимании истинных возможностей тестирова- 
ния и его потенциального вклада в общее дело. Большинство из них с готов- 
ностью выслушивали меня. Некоторые не были готовы к восприятию моей 
точки зрения. Если вы сталкиваетесь с нереалистичными ожиданиями, по- 
пытайтесь понять мотивацию людей, их высказывающих. Что для них пред- 
ставляет ценность? О чем они беспокоятся? Чем они занимаются в свобод- 
ное время, и можно ли использовать сравнения, чтобы облечь вашу точку 
зрения в близкую для них форму. Общайтесь на понятном им языке. 

Если это не действует, если кто-то упрямо цепляется за свои нереали- 
стичные ожидания, тогда уже вам придется реально оценить собствен- 
ные возможности. Вы можете продолжать работать с этим человеком, 
зная, что время от времени вас будут в чем-то несправедливо обвинять. 
Или же вы можете найти другую работу . 


Взаимоотношения 


Слишком часто я слышал и сталкивался с ситуациями, в которых роль 
группы тестирования рассматривалась, по сути, в виде противостояния 
остальным группам проекта. Тем не менее, группы тестирования часто 
являются подразделениями, предоставляющими услуги. Сервисные под- 
разделения либо удовлетворяют потребности заказчиков, либо выходят 
из игры. Очевидно, что отношения, построенные на соперничестве, ука- 
зывают на отсутствие удовлетворенности. Хотя вопрос о том, как в согла- 
сии работать с другими людьми, выходит за рамки данной книги, я могу 
предложить несколько коротких советов по поводу этих проблем приме- 
нительно к специфике работы тестировщика. 

Прежде всего, убедитесь в том, что вы контролируете все возможные 
нереалистичные ожидания. Многие из проблем во взаимоотношениях 
с руководителями берут начало в нереалистичных ожиданиях. Во-вто- 
рых, совместно со своими коллегами и руководителями проясните все 
роли, отношения и передачи материалов, влияющие на процесс тестиро- 


1 См. мою статью "бор Юеѕігоуіпр Му Теаш ий Ваа МВОз: А Мапарег'ѕ Мем Уеагз 


Кезоїшіоп" на ммумг.3скутіпаз.сота, где приведены размышления по поводу того, как нереа- 
листичные ожидания превращаются в измеряемые цели производительности, и показано, 
почему это плохо. | 
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вания. В-третьих, подумайте о том, кто является вашими внутренними за- 
казчиками и заинтересованными сторонами. Вот несколько примеров: 


и Разработчики, нуждающиеся в помощи в тестировании и отладке 


= Сотрудники служб маркетинга и продаж, стремящиеся продвинуть 
на рынок и продать качественные системы 


м Бизнес-аналитики и заказчики, которые хотят получить качествен- 
ные системы 


и Сотрудники службы технической поддержки, не желающие иметь 
дело с сердитыми заказчиками 


и Администраторы сети, которые хотят, чтобы серверы работали на- 
дежно и были масштабируемы 


Вам удастся выстроить надежные взаимоотношения с этими людьми, 
если вы сможете предложить им конкретные услуги. 

И последнее. Займитесь созданием крепких взаимоотношений на ран- 
них этапах проекта, прежде чем проявятся паника и стресс, так часто со- 
путствующие конечным стадиям проекта. Такие взаимоотношения будут 
приносить отдачу на протяжении всего проекта, не только делая вашу ра- 
боту менее нервной, но и превращая процесс тестирования в более эф- 
фективный и производительный как с объективной точки зрения, так 
и в глазах ваших коллег. 


“Привычка тестировать” 


Некоторые компании организуют независимые группы тестирования, пы- 
таясь справиться с особенно тяжелым (и дорогим) проектом или обеспе- 
чить составляющую работ по совершенствованию процесса разработки 
программных продуктов, направленного на улучшение качества. Как пра- 
вило, новая группа тестирования призвана концентрировать усилия на 
поведенческом тестировании, часто на этапах комплексного и системного 
тестирования, а также во время приемо-сдаточных испытаний, тогда как 
программисты по-прежнему отвечают за структурное тестирование и за 
большую часть работ на этапах компонентного и модульного тестирования. 

Однако иногда лишь первая часть данного мероприятия “пускает кор- 
ни”, в то время как тестирование, которое должны проводить программи- 
сты, сходит на нет. Программисты, ранее считавшие себя ответственны- 
ми за все тестирование собственного программного продукта, перестают 
что-либо делать, размышляя так: “Ага! Мне больше не нужно тестировать, 
это работа группы тестирования”. 

Мой коллега Рэн Макнари говорит о такой ситуации, что программи- 
сты “привыкли тестировать”. Но когдаони прекращают этим заниматься, 
качество системы, поступающей тестировщикам, становится более низ- 
ким, чем до организации независимого тестирования, когда система 
поступала к пользователям или заказчикам непосредственно от группы 
разработчиков. В результате возникает последовательность из трех чрез- 
вычайно опасных ситуаций, одна за другой ударяющих по проекту и, разу- 
меєтся, по группе тестирования. 
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Во-первых, интеграция разнообразных компонентов после их завер- 
шения становится сложной. Поскольку сами компоненты содержат про- 
блемы, на то, чтобы “заставить” их работать вместе, требуется много вре- 
мени, и в ходе подобных попыток выявляется много проблем. Эти 
проблемы сложно отделить друг от друга, что порождает споры, в кото- 
рых программисты, создавшие “недружественные” компоненты, обвиня- 
ют друг друга в ошибках. И лишь благодаря титаническим усилиям со сто- 
роны руководства интеграция продолжается. Вследствие того что 
затраты на интеграцию компонентов в любом случае часто недооценива- 
ются в планах-графиках проекта, это может привести к существенным и 
непредвиденным отставаниям в середине проекта. 

Во-вторых, когда с интеграцией системы справляются, ее передают 
независимой группе тестирования в чисто функциональном виде, и она 
переполнена критическими ошибками. Из-за отставания по срокам задер- 
живается начало комплексного и системного тестирования, причем соот- 
ветствующего сдвига в окончании работ по тестированию часто не про- 
исходит, поскольку руководство объявляет дату поставки проекта или 
выпуска системы неприкосновенной. Появляется надежда, что “во время 
тестирования мы наконец получим передышку”, но на самом деле тести- 
рование занимает значительно больше времени, чем первоначально пла- 
нировалось. Это происходит не только потому, что, так же как интегра- 
ция, тестирование недооцениваєтся, но и потому, что продукт 
оказывается хуже ожиданий, а значит и тестирование идет значительно 
медленнее, чем могло бы. Критические блокирующие ошибки приводят к 
невозможности нормального прохождения тестов согласно плану. Но- 
вые тестовые сборки показывают отсутствие ключевых функций, в неко- 
торых случаях сборки даже не могут бытьустановлены. Нередко именнос 
этими проблемами связан полный крах того или иного проекта, когда 
терпение руководства, финансовые возможности или даже жизнеспособ- 
ность компании в целом исчерпывается. 

В-третьих, когда необходимо сплотиться вокруг проекта и развернуть 
или выпустить систему, результаты нередко бывают неутешительными. 
Группа тестирования тратит большую часть времени и сил на поиск оши- 
бок при помощи поведенческих методик, в то время как те же ошибки 
можно было выявить раньше и с меньшими денежными затратами, если 
бы программисты провели тестирование структурными методами. Таким 
образом, они находят меньше ошибок, что означает, что больше ошибок 
останется в программе. Когда к этим трем ситуациям добавляются нереа- 
листичные ожидания по поводу группы тестирования, руководство ино- 
гда возлагает всю вину на тестировщиков . 

Чтобы этого не произошло, начните с устранения каких бы то ни было 
нереалистичных ожиданий, сложившихся в головах ваших коллег отно- 


Существует показатель, который вы, будучи тестировщиком, можете применять для ко- 
личественной оценки эффекта чрезмерной веры в тестирование на поздних этапах, он на- 
зывается “процент выявления дефектов”. Узнать об этом показателе более подробно можно из 
моей книги “Мапаріпр Ше Тезійпр Ргосезз, З5есопа Еайісп. В статье Элизабет Хендриксон 
(Еіѕаресћ Непагіскѕоп) “Моге Теѕііпр, М/огзе ОцаНу» на сайте мили. апаШеугее.сот вы найде- 
те учебную ситуацию, посвященную “привычке тестировать”. См. также статью Ли Коплэн- 
да “УЋеп Нарще Ооеѕп' Не!р» на ми. 5исКупи!п95.сот. 
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сительно того, что группа тестирования в действительности в состоянии 
сделать. Убедитесь в том, что группа разработки знает о необходимости 
продолжать нести ответственность за структурное тестирование. После- 
довательно требуйте от руководства проектом выполнения своей части 
обязательств по поводу ответственности за этапы модульного или компо- 
нентного тестирования (в соответствии со сроками, планом и адекватны- 
ми ресурсами), которые ясно оговорены и активно отслеживаются по 
графикам проекта. И, наконец, используйте приемочное тестирование и 
вводите входные критерии для измерения и определения уровней качест- 
ва системы, необходимых для перехода к комплексному и системному тес- 
тированию. 


Постепенное совершенствование процесса 


Возможно, сейчас вы думаете: “Ну, знаете, наши процессы достаточно хоро- 
ши. Я не желаю делать какиелибо коренные преобразования. Я лишь хочу, 
чтобы мы делали свою работу чуть лучше”. С этой целью позвольте мне пред- 
ложить несколько подходов общего назначения, применяемых мной для оп- 
тимизации процессов тестирования. Эти подходы относятся кодной из двух 
категорий. Первая — точная регулировка больших процессов. Второй — вы- 
явление и попытка устранения препятствий в больших процессах. 


Точная регулировка больших процессов 


Прежде всего, начните с изучения тех процессов, которые занимают 
большую часть времени, сил или ресурсов. Вот простой метод оптимиза- 
ции процессов, который яузнал, изучая тотальное управление качеством. 
Я применял этот подход в тех компаниях, где имелся работающий про- 
цесс тестирования, но была потребность в его совершенствовании!. 
Начните с рассмотрения двенадцати ключевых процессов тестирова- 
ния. Выберите два или три из них, те, что занимают у группы тестирова- 
ния две трети или более времени, сил или ресурсов. К примеру, неудиви- 
тельно, если вы выясните, что составление отчетов об ошибках и процесс 
проведения тестов составляют две трети от работ группы тестирования. 
Для этих ключевых процессов преобразуйте списки контрольных во- 
просов, представленные в данной книге, таким образом, чтобы они под- 
ходили для ваших текущих потребностей и давали возможность собирать 
информацию о продолжительности, затратах ресурсов, и, если можно, 
о стоимости каждого этапа. (Возможно, у вас уже имеются какие-то дан- 
ные по итогам выполнения тестовых сценариев, если вы начали приме- 
нять таблицы отслеживания тестовых сценариев, представленные в гла- 
ве 13.) По мере того как вы и ваша команда будете заниматься каждым 


1 м 
Это обучение являлось частью сертификационной программы по тотальному управлению 


качеством в Калифорнийском университете в Лос- Анжелесе. С точки зрения постепенного 
совершенствования процесса, самыми полезными были занятия, проводимые корпоратив- 
ной службой обучения компании Хегох “Лидерство благодаря качеству', в особенности “Теоре- 
тические основы качества", “Процесс улучшения качества” и “Процесс решения проблем”. 
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процессом, собирайте данные о продолжительности, затратах ресурсови 
стоимости каждого этапа работ. Для мелких процессов длительность и за- 
траты следует собирать с точностью до минут. 

К процессу сбора этих данных применимы все обычные предостере- 
жения относительно использования измерений. Если у работников ком- 
пании сложится впечатление, что руководство станет использовать дан- 
ную информацию против них, они исказят данные таким образом, чтобы 
создавалось благоприятное впечатление об их работе. Если сотрудники 
решат, что эти данные нужны руководству в качестве показателей для 
ежегодной аттестации, они будут подтасовывать информацию. Если 
ваши коллеги сочтут, что руководство будет применять эти данные, что- 
бы сравнить одних специалистов с другими, ранжируя их по эффективно- 
сти, может даже начаться взаимная подрывная деятельность, ведущая к 
разрушению сплоченности команды. Вам вряд ли захочется во имя совер- 
шенствования процессов разрушать свою команду. 

После того как у вас наберутся данные об исполнении процесса каж- 
дым членом группы тестирования примерно в десятке случаев, проанали- 
зируйте их. Каковы средние величины по каждому этапу и для всего про- 
цесса в целом? Каковы колебания для каждого этапа и для всего процесса? 
Классическая теория совершенствования качества гласит, что для улуч- 
шения производительности процесса нужно снизить колебания вокруг 
средней величины, а затем изменить ее в желаемом направлении. Однако 
в отношении процесса тестирования эту аксиому нужно применять с ос- 
торожностью, поскольку “быстрее” не обязательно означает “лучше”, 
и для широкой амплитуды колебаний могут существовать вполне разум- 
ные причины. 

В ходе анализа полученных данных разделите имеющуюся информа- 
цию по показательным важным факторам. Рассмотрите данные как по ка- 
ждому тестировщику, так и по всей команде. Каков уровень индивидуаль- 
ных колебаний? В случае с отчетами об ошибках изучите данные об 
ошибках разных уровней приоритетности и серьезности, поскольку 
предполагается, что на составление отчетов о более важных проблемах 
требуется больше времени. При исследовании выполнения тестов кон- 
троль колебаний зависит от количества ошибок, обнаруженных при по- 
мощи теста, а также от времени настройки и удаления теста. Как изменя- 
ются данные для автоматизированного тестирования по сравнению с 
данными, полученными для тестирования вручную? В статистический 
анализ данных по процессу очень легко могут вкрасться ошибки, если вы 
смешаете данные по процессам, которые по веским причинам проходят 
по- разному. 

Проведя данный анализ, займитесь поиском основных причин. У кого- 
то из вашей команды трудности с локализацией ошибок? Возможно, ему 
нужно пройти курс обучения. У всех членов группы проблемы с локализа- 
цией? Может быть, у вас нет достаточного количества альтернативных 
конфигураций системы, и следует собрать библиотеку образов дисков для 
ускорения изменения конфигураций. Каждый понедельник после уста- 
новки новой сборки процесс предоставления отчетов об ошибках замед- 
ляется? Возможно, чрезмерно высокая насыщенность ошибками каждой 
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новой сборки приводит к путанице по поводу того, кто какую ошибку от- 
слеживает. 

Может статься, что для проверки ваших гипотез относительно основных 
причин задержек вам придется собрать дополнительные данные, однако из- 
бегайте ситуации, когда анализ парализует ваши дальнейшие действия. Если 
интуиция подсказывает вам, что можно внести простые изменения, кото- 
рые имеют низкий риск (т.е вероятность того, что они срикошетят и еще бо- 
лее усугубят ситуацию, крайне мала), то можно сделать это без сбора допол- 
нительной информации. С другой стороны, рискованные и дорогие 
преобразования требуют дополнительного анализа. Если вы хотите приоб- 
рести аппаратное обеспечение на $100 000 для того, чтобы быстрее прово- 
дить локализацию ошибок, необходимо собрать информацию, свидетельст- 
вующую о том, что нехватка аппаратного обеспечения является основной 
причиной продолжительной локализации дефектов, и разработать обстоя- 
тельный бизнес-план, окупающий инвестиции. 

Внеся изменения в процесс, время от времени рассматривайте затра- 
ты ресурсов, чтобы со временем перейти к их сокращению. Сразу про- 
цесс неулучшится. Собирайте данные и наблюдайте за тем, как протекает 
совершенствование процесса. Если улучшения ситуации не происходит, 
прежде чем переходить к дальнейшей оптимизации, выясните, почему 
ваши преобразования не оказали желаемого влияния. Если же улучшения 
имели место, дождитесь, когда этот новый процесс стабилизируется, 
и только после этого переходите к дальнейшей оптимизации. Повторяй- 
те процесс оптимизации снова и снова. 

Не все процессы, на выполнение которых требуется больше времени, 
усилий или затрат, непременно самые худшие. В случае с отчетами об 
ошибках может оказаться, что один из ваших сотрудников всегда тратит 
много времени на их составление, однако его отчеты непременно самые 
лучшие. Вы врядли захотите оптимизировать время, затраты сил и ресур- 
сов, но при этом игнорировать основное предназначение процесса. Вво- 
дите лишь те усовершенствования, которые позволяют повысить произ- 
водительность, не понижая эффективность вашей команды. На самом 
деле, улучшения следует организовывать таким образом, чтобы они, по 
возможности, оптимизировали и эффективность. Совершенствуя про- 
цесс, продолжаете его проверять на предмет качества результатов, ис- 
пользуя разделы данной книги, посвященные построению успешных про- 
цессов. 


Выявление и устранение крупных препятствий для процессов 


Распространенной причиной неэффективности процесса являются бес- 
полезная трата ресурсов и переделывание работы. Методика оптимиза- 
ции процесса, применяемая мной, заключается в отслеживании распро- 
страненных предпосылок для бесполезной траты времени, сил и других 
ресурсов. Пусть сотрудники вашей группы каждую неделю докладывают 
вам о любых случаях, в результате которых потеряно более одного часа 
прописанного в графике времени, одного часа затрат (личное время) или 
ресурсов на сумму свыше $100, если подобных трат можно было избежать. 
(Если вас не устраивают эти пороговые величины, выберите другие, бо- 
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лее подходящие в ваших условиях.) В качестве примеров каждого из ви- 
дов потерь можно привести: находящийся в режиме оффлайн сервер, ко- 
торый используется для обычного сопровождения в период, отведенный 
но графику на тестирование; прогон тестов по старой тестовой версии; 
ланч для группы тестирования в пятнину по причине того, что она не мо- 
жет продолжать работу из-за проблем с материально-техническим обес- 
печением соответственно. 

После того как вы соберете эти данные, разбейте их на категории и по- 
стройте таблицы для сбора дальнейшей информации. Целью подобных 
мероприятий является уже не сбор статистических данных по поводу са- 
мих процессов тестирования (мы только что проделали это для точной 
регулировки процессов, см. выше), а выявление помех в процессе тести- 
рования. События, отнесенные вами к напрасной трате времени, не 
должны включаться в перечень задач, отражаемых в списках контроль 
ных вопросов по процессам. Эти события — неожиданные препятствия, 
которые мешают вашей группе тестирования работать эффективно 
и производительно. 

Еще раз повторяю, не забывайте о распространенном отношении к ко- 
личественным показателям. Если тестировщики считают, что вы исполь- 
зуете информацию против них, они исказят данные в свою пользу. Если 
люди, не работающие в вашей компании, решат, что вы собираете эти 
данные в качестве оружия против них, возникнут огромные трудности. 
Руководство ненавидит напрасное использование ресурсов и переделы- 
вание работы, поэтому имеющаяся у вас информация потенциально 
взрывоопасна, если попадет не вте руки. Во многих компаниях вам при- 
дется быть очень осмотрительным на предмет того, кто будет в курсе, что 
вы собираете подобную информацию. 

Собирая данные, вы со временем столкнетесь с действием правила 
80/20 или принципа Парето. Важными будут два или три источника на- 
прасной траты ресурсов, которые обуславливают две трети или более по- 
добных случаев. Остальные будут менее значимыми. В отношении каждо- 
го важного источника бесполезного расходования ресурсов составьте 
план по улучшению процесса, направленный на устранение ненужных за- 
трат. Например, если постоянным источником проблем являются пло- 
хие тестовые версии, перечитайте главу 12 и затем введите для решения 
данного вопроса, скажем, приемочное тестирование . 

Разрабатывая план улучшения процесса, продолжайте собирать дан- 
ные. Возможно, вы увидите, что в действительности, прежде чем ситуация 
начнет улучшаться, проблем становится еще больше (изменение процесса 
означает непроизводственные издержки и способно смутить вас). Не пред- 
принимайте сразу ответных действий. По прошествии некоторого време- 
ни (нескольких месяцев или нескольких проектов) вы увидите, что новый 
процесс стал привычным для вашей группы. Когда это произойдет, напрас- 
ная трата времени, связанная с целевым источником (или источниками) 
должна снизиться. Как только источники подобной траты стабилизируют- 


* Отличным способом сбора подобнсй информации может служить база данных управле- 


ния изменениями, описанная в главе 6 книги “ Маларіпо #е Тезіїпр Ртосеѕѕ, Зесопа Еф от” и 
включенная вместе с другими шаблонами в приложение х этой книге. 
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ся, вновь приступайте к сбору данных для улучшения процесса. Каковы те- 
перь два или три источника двух третей напрасной траты ресурсов? Пора 
составлять новый план по улучшению процесса. 


Внедрение усовершенствований 


Итак, возможно, вы хотите внедрить крупные изменения в процесс тес- 
тирования в вашей компании. Каковы идеи по поводу серьезных преобра- 
зований процесса тестирования? 


1. Выявите пробелы в ваших текущих процессах тестирования. Эта 
книга и, например, книги " Тез! Руосеѕѕ Їтргодетепі" Коомена и Пола и 
“Тре Тезіто Руасійіопе?" ван Веенендааля должны обогатить вас идея- 
ми. Продолжайте концентрировать внимание на процессах тестиро- 
вания, находящихся в вашей компетенции, поскольку вы действи- 
тельно можете изменить их. Используйте такие источники данных, 
как системы по отслеживанию ошибок, системы сетевой поддерж- 
ки, данные об отказах в период эксплуатации и результаты проведен- 
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ных ранее тестов, но будьте также готовы прислушаться к более 
субъективным, но обоснованным интуитивным соображениям. 


Выявите преимущества и недостатки изменения процесса для каж- 
дого слабого места. Является ли потребность в преобразованиях 
непосредственной и срочной или долгосрочной и существенной? 
Каковы риски и затраты, связанные с текущим стилем работы? 
В чем заключаются возможности и преимущества изменения про- 
цесса? Существуют ли личные, политические или практические 
причины для преобразований? 


Выберите идеальные изменения процесса, к которым следует при- 
ступить. Делая выбор, не забывайте, что на него могут оказать влия- 
ние личные, политические и практические воздействия. Вам по- 
требуется дополнить эти воздействия четким бизнес-планом. 


Планируйте изменения. Выявите заинтересованные стороны, на 
которых отразятся изменения. Некоторые заинтересованные сто- 
роны могут ратовать за сохранение имеющихся процессов, значит, 
вам придется каким-то образом убедить их. Внедрение ограничен- 
ных изменений процесса как элемента отдельно взятого проекта 
обычно менее рискованно в политическом плане и при этом мудро 
с точки зрения содержания, а следовательно, это спокойнее вос- 
принимается. Изменить внутренние процессы проще, чем процес- 
сы, в которые вовлечено много сторон. Менее контекстно-зави- 
симые процессы менять легче, чем более контекстно-зависимые. 


Убедите коллег в разумности вашего плана по изменениям процес- 
са. Поймите сами и разъясните другим, каковы риски запланиро- 
ванных изменений и в чем заключаются их преимущества. 


Приступайте к изменениям, тщательно фиксируйте преимущества, 
как только они начнут проявляться. Будучи менеджером, вырабо- 
тайте соответствующие изменения в своем поведении для поддерж- 
ки изменений, внесенных в процесс!. Если вносимые изменения су- 
щественны, ситуация может сначала ухудшиться. Как и в случае 
с тестированием, расходы на изменение процесса увеличиваются, 
прежде чем появляются преимущества, потому важно возобновить 
аргументацию причин, вызвавших необходимость преобразова- 
ний, и напомнить о конечной выгоде. 


Закрепляйте изменения. Порой происходят изменения к лучшему, 
ситуация исправляется, а затем компания возвращается к старому, 
дисфункциональному поведению. Важно продолжать работать в 
выбранном направлении. Добейтесь того, чтобы общая культура 
группы тестирования или организации работ по созданию про- 
граммного продукта изменилась таким образом, чтобы новый про- 
цесс стал привычным. 


Более подробную информацию о трудностях и препятствиях, которые руководство в со- 
стоянии создать на пути внедрения изменений в процесс, можно найти в статье Джоанны 
Ротман "Мапарег Неа! ТБузеї?" на муу готпап.сот. 
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8. Вернитесь к первому этапу и проделайте все сначала. Компании, до- 
бившиеся успеха на ниве совершенствования, имеют обыкновение 
превращать это занятие в привычку. Всегда можно что-то сделать 
лучше. Всегда найдется то, что можно усовершенствовать. Именно 
эта привычка, заключающаяся в постоянном улучшении процес- 
сов, и отличает действительно выдающиеся компании по разработ- 
ке программного обеспечения, наиболее зрелые организации, ко- 
торые являются лидерами в своей области. 


Нередко, чем крупнее преобразования, тем медленнее происходит 
прогресс в изменении процесса. Для внедрения нового способа составле- 
ния отчетов об ошибках в группе тестирования, состоящей из десяти че- 
ловек, тест-менеджеру может потребоваться квартал. Часто получение 
преимуществ начинается с момента введения изменения. Вице-прези- 
дент по разработке программного обеспечения, внедряющий формаль- 
ный процесс тестирования, с самого начала может рассчитывать на то, 
что успех придет через год работы над этим изменением. В силу того, что 
многие компании, специализирующиеся на тестировании, оказываются 
не у дел в течение первых двух лет со дня основания, важно, чтобы изме- 
нения, проводящиеся в это время, были осторожными, тщательно обду- 
манными и направленными на получение максимальной пользы. 


Джамал Браун оглядывается назад 
и смотрит вперед 


31 марта после обеда Джамал сидел у себя в офисе за закрытыми дверями 
и размышлял над успехами и неудачами проекта “Суматра”. Заключитель- 
ное совещание прошло 28 марта, всего лишь с недельным отставанием. 
Задержка была вызвана необходимостью завершить один заключитель- 
ный полный раунд тестирования после получения в каком-то смысле рис- 
кованной тестовой версии, основная ошибка в которой была устранена 
14 марта. Кандидат в золотую сборку благополучно прошел тестирова- 
ние. По крайней мере, существенных ошибок не было выявлено. Поэтому 
в пятницу вечером было решено выпустить систему. На этом совещании 
Джамал представил последний отчет о тестировании, дав общее заключе- 
ние, в котором говорилось, что как известные, так и неизвестные риски 
качества невысоки и более не могут служить основанием для задержки 
выпуска версии. Сразу по окончании данного собрания Джамал, с разре- 
шения менеджера, уехал за город на выходные, вернувшись на работу в 
понедельник в 11 часов утра. 

Следующей должна была стать работа над внедрением возможностей 
поставщика услуг по аренде приложений (АЅР) в ЗреедуУутітег 3.1 — так те- 
перь официально называли Суматру. Но прежде всего Джамал должен 
был подготовиться к собранию, посвященному подведению итогов по 
проекту “Суматра”. Собрание было намечено на утро следующего дня. 

Джамал готовил свою часть тезисов по итогам проекта. Он на минуту 
задумался, позвонил кому-то из рабочей группы проекта и поговорил 
с ним, с минуту набирал текст, открыл книгу, внимательно прочитал элек- 
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тронные письма по проекту, взглянул на отчет о ходе тестирования и за- 
тем повторил эти действия. Несколько часов спустя все было готово. Он 
распечатал документ для всех участников совещания и пошел домой, ос- 
тавив на рабочем столе аккуратную стопку копий документа, содержаще- 
го тезисы. Выключая свет, Джамал взглянул на свой стол, улыбнулся и по- 
думал: “В этот раз мы почти все сделали правильно”. 


№ этапа Этап Выполнено? 

4. Совершенствование: предоставление информации о проекте | 
и его улучшение. 

4.А Документировать ошибки, обнаруженные в ходе выполнения 
тестов. 

4.В Обсудить результаты тестирования с ключевыми заинтересо- 
ванными лицами. 


4.С Управлять изменениями и уточнить процесс тестирования Ы 
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Группа тестирования сосредоточила с силы на а предоста ении высокока- - 
чественной информации | 


9 ло що неудачным. о ; 
по моему мнению, они в большей сти относились 
К таким ситуациям, С. которыми практически всегда возникают сложности. 

Как бы то ни было, замеченньк. возможностям по, и 
Пе. относятся і 


т риск, связанный с сокращением времени 
Возможности по исправлению ситуации: 


оизошло, проведенное нами тестирование было бы 
значительно. менее эффективным, особенно для. первы». нескольких ине: 
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Снижение: затрат расчете на дефект, подлежащ 
рты в и на лан под 


ак с правило, дают лучший результат, чем. регрессионные, 
«В виду: того, что ключевым номем наа ее. риском регрес 


ния, й хак на уровне 
| уевано слоев 'бизнеслогики ар с 


Заключение 


В этой книге содержатся идеи по совершенствованию процессов тести- 
рования. Представленные процессы описывают мой собственный под- 
ход к тестированию и управлению им. Учебная ситуация является живым 
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примером работы данных методов. Изучая документы обучающего при- 
мера, вы получите примеры и шаблоны, которые могут облегчить про- 
цесс “перекройки” моих методов под ваши потребности, если у вас воз- 
никнет желание применить полученные знания. И, наконец, разделы, 
посвященные построению успешных процессов, решению проблем и 
внедрению усовершенствований, призваны помочь вам понять, как про- 
двигаться в этих направлениях. Упорное, продуманное совершенствова- 
ние двенадцати ключевых процессов тестирования поможет вам эффек 
тивно и качественно готовить и передавать информацию по управлению 
рисками качества и оказывать услуги в рамках выстроенных вами процес- 
сов тестирования. 

Тем не менее, позвольте мне закончить книгу предостережением и сде- 
лать признание, что сам по себе процесс не может творить чудеса. Прежде 
чем профессиональный сленг управления качеством привел нас к беседе 
о процессах, мы рассмотрели способы решения проблем как системы. На- 
личие систематического подхода при выполнении некоторой работы оз- 
начаєт, что имеется зафиксированный и повторяемый процесс. Русский 
классик Иван Тургенев писал: “Системами дорожат только те, которым вся 
правда в руки не даётся, которые хотят её за хвост поймать; система — точ- 
но хвост правды, но правда — как ящерица; оставит хвост в руке, а сама убе- 
жит: она знает, что у нее в скором времени другой вырастет”. 

Иван Тургенев прав, поскольку процесс может оказаться сдерживаю- 
щим. И если им пользоваться неверно, так и происходит. Однако если вы 
направите свои силы на то, что оказывает в конкретной ситуации сущест- 
венное влияние на эффективность и качество тестирования, процесс мо- 
жет стать полезным руководством к действию. Грамотный процесс ока- 
жет вам услугу, освободив от необходимости каждый раз вновь 
придумывать, как добиться успеха. Процесс может выступить в роли кон- 
трольного списка вопросов и направить вашу творческую энергию на ре- 
шение более существенных проблем, нежели просто заботиться о том, 
чтобы ничего не упустить из виду. Удачи вам в работе с ключевыми про- 
цессами тестирования и всеми другими важными составляющими успеха 
в тестировании! 


ГЛОССАРИЙ 


Приемо-сдаточные испытания, пользовательское приемочное тестирование 
(Ассергапсе Теѕіпр, Озег Ассеріапсе Тези). Фаза тестирования, целью которой 
является проверка того, что система удовлетворяет требованиям. Название "поль- 
зовательское приемочное тестирование” может указывать на то, что тестирование 
проводится силами пользователя. 


Активность, действие (АсПіуїу). Логически выделенная часть фазы, состоящая 
из набора задач, выполнение которых означает получение одного существенного 
передаваемого результата. 


Альфа-тестирование, бета-тестирование (Аірһа Тез@пв, Вега Теѕіпр). Фазы тес- 
тирования, в ходе которых система подвергается проверке со стороны внутрен- 
них (альфа) или внешних (бета) заказчиков и пользователей в реальных услови- 
ях, на настоящих данных и в реальной среде. 


Амортизация (Атогіе). Распределение затрат и прибыли от инвестиций на се- 
рии временных периодов (например, ежемесячно) либо на совокупность проек- 
тов. Показывает средние затраты и среднюю прибыль от инвестиций на период 
времени или на проект. | 


Навыки в предметной области приложения, экспертиза в предметной облас- 
ти (Арріїсачоп Рота 5Кії5, Ѕиђјесі Мацег Ехрегизе). Навыки или знания, от- 
носящиеся к какой-либо области или к решаемым задачам в программном или 
аппаратном обеспечении; другими словами, понимание того, как заказчики и 
пользователи будут применять создаваемую систему. 


Выполнение контрольных заданий (Аи оп Нцеглем). Часть процесса интер- 
вьюирования при приеме на работу, которая посвящена показу умений и навы- 
ков, необходимых для занятия вакансии, например написанию тестового сцена- 
рия или подготовке отчета об ошибке. 


Система сбалансированных показателей (Ва!апсе4 Зсогесага). См. Инструмен- 
тальная панель (Оаѕћоага) 


Тестирование поведения системы, тестирование методами “черного ящика" 
(Вераміога! Теѕ‹ѕ, Віаск-Вох Тезі5). Тестирование на основе внешнего поведения 
системы, часто апеллирующее к требованиям и спецификациям архитектуры вы- 
сокого уровня. 


Бета-тестирование (Веїа Теѕііпр). См. Альфа-тестифование (А1рһа Теѕіпр) 


Тестирование методами “черного ящика”. См. Тестирование поведения системы 
(Вераміога! Теѕіѕ) 


528 


Глоссарий 


Ошибка, дефект (Вир, Оеѓесі). Проблема, которая вызывает или может вызвать не- 
адекватное выполнение системой одного или нескольких обоснованных ожида- 
ний качества заказчика / пользователя. | 


Отчет об ошибке (Вир Керог.). Технический документ, описывающий симптомы 
ошибки для 1) информирования о влиянии и обстоятельствах возникновения про- 
блемы; 2) назначения ошибке приоритета для исправления; 3) помощи программи- 
сту в локализации дефекта и его исправления. 


Сборка, версия, тестовая версия (Виїї!й, Вееазе, Тезі Ке]еазе). Устанавливаемый 
компонент аппаратно-программного обеспечения или системы либо система це- 
ликом, передаваемая группе тестировщиков для тестирования. 


Номер сборки, имя сборки, версия, номер версии (Ви! Ш, В@еазе Мате, 
Кеуіѕіоп, Веуізіоп МипЪег, Мегѕіоп, Уегѕіоп Мишрег). Уникальная последователь 
ность цифр и/или букв, однозначно определяющая сборку. 


Вий Мапағег. См. Инженер сборки (Веісазе Епртеег) 


План сборок (Виї!4 Ріап, Ке!еазе Епртеегир Р1ап). План, определяющий, каким 
образом будут строиться сборки для тестирования в реальных условиях. 


Кандидат (Сапдїдаге). Человек, подавший заявление на занятие вакансии и нахо- 
дящийся на рассмотрении, но еще не принятый официально. 


Кодируй и исправляй (Соде апа Вх). Подход к разработке, исключающий боль- 
шинство действий по планированию, сбору требований и проектированию, начи- 
нающийся непосредственно с кодирования системы с последующим исправлени- 
ем обнаруженных ошибок. Обнаружение ошибок ведется посредством 
формального тестирования независимой группой тестировщиков, либо при по- 
мощи неформального (ад Вос) тестирования, либо только при отладке. Данная 
модель может быть удобна для небольших, несложных проектов разработки или 
поддержки с невысоким уровнем рисков. Модель не подходит для больших, слож- 
ных проектов и проектов с высоким уровнем рисков. 


Компонентное тестирование, тестирование подсистем (Соптропепі Теѕііпӯ, 
Зиъзуцет Тезії пе). Фаза тестирования, ориентированная на проверку компонен- 
тов системы и/или ее подсистем по отдельности. 


Критическая сеть (Сгіцса МегуогК). См. Критический путь (Спаса! Ра). 


Критический путь, критическая сеть (Сгіцса! Рав, Сгійса! МегуогК). Совокуп- 
ность задач (в терминах длительности действий и задач) в структурной декомпо- 
зиции проектных работ (с учетом всех межзадачных взаймозависимостей), кото- 
рые должны завершиться к определенному моменту для того, чтобы проект был 
завершен в срок. 


Заказчики, спонсоры (Сизотегз, бропзогз). Люди, финансирующие создание 
системы любым из следующих способов: непосредственная оплата разработки 
системы, участие в финансировании системы, финансовая поддержка произво- 
дителя системы, приобретение продукта или службы, содержащей или исполь 
зующей систему, оплата налогов, прочие прямые и косвенные способы финанси- 
рования. Заказчик — это организация, приобретающая и/или поставляющая 
систему для пользователей, являющихся сотрудниками организации, или частное 
лицо, приобретающее систему для личного пользования. 


Инструментальная панель, система сбалансированных показателей 
{РазНБоага, Вајапсеа Зсогесага). Это набор метрик, которые обычно представле- 
ны в виде небольшого числа диаграмм или графиков. Они дают представление о 
текущем статусе некоторой деятельности. Аналогией здесь является приборная 
доска автомобиля, на которой набор из двух-трех измерительныхустройств и пре- 
дупреждающие светодиоды обеспечивают водителя важной информацией о со- 
стоянии транспортного средства, не отвлекая его от наблюдения за дорогой и 
движением. Термин "система сбалансированных показателей” означает тот факт, 
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что при удачном подборе диаграммы или графики такого рода дополняют друг 
друга. Иными словами, любое, отдельно взятое измерение может склонить к не- 
верным выводам, тогда как кумулятивный эффект всех метрик должен образовать 
контекст для других измерений. 


Дефект (Реѓес!). См. Ошибка (Вов) 


План разработки (Реуеіортеп“ Ріап). План, определяющий, каким образом бу- 
дут создаваться компоненты, составляющие систему, включая последователь 
ность разработки компонентов. 


Оценка (Еѕўтайоп). Прогноз графика работ и затрат в проекте. В случае оценки 
тестирования это прогноз графика работ и затрат подпроекта тестирования. 


Ожидание качества (Ехресіайоп ої Орау). Убежденность заказчика / пользова- 
теля вуровне качества, который должна обеспечивать система. В идеале заказчи- 
ки и пользователи должны иметь обоснованные ожидания качества системы. 


Необоснованные ожидания обычно вызывают остановку таких действий, как 
сбор требований, бизнес-анализ и управление изменениями. Часто невозможно 
и, как правило, нежелательно пытаться следовать необоснованным ожиданиям 
качества при проведении тестирования. 


Опыт качества (Ехрегіепсе ої ОџаШу). Мнения о качестве системы вместе с об- 
щим уровнем удовлетворенности пользователей /заказчиков по мере получения 
опыта работы с системой: Когда уровень опыта качества совпадает с ожиданием 
качества, пользователь / заказчик обычно удовлетворен. Если опыт качества пре- 
вышает ожидания, пользователь /заказчик восхищается. Если опыт качества 
ниже ожиданий, пользователь / заказчик разочарован. 


Дополнительные смены (Ехѓіепіеа Ѕһіѕ). Любая работа, выполняемая сотруд- 
никами вне основного рабочего времени (примерно с 8.00 до 17.00). Обычно это 
вечерняя смена (примерно с 16.00 до 1.00), ночная смена (примерно с 0.00 до 9.00), ра- 
бота в выходные и праздничные дни (любая из указанных смен, но не в рабочие дни). 
Сравните с переработкой (омегіїте) — работа свыше 40 часов в неделю, может 
включать в себя работу в любые смены. 


Вид ошибки (ЕаЙиге Моде). Определенный способ возникновения или тип ошиб- 
ки в системе, т.е. категория ошибок или сбоев с определенными отличительными 
общими признаками. Одному виду ошибки могут соответствовать ноль, одна и бо- 
лее отдельно взятых ошибок или неисправностей. При рассмотрении вида ошибки 
в любом варианте анализа рисков качества необходимо тщательно выверять сте- 
пень детализации категорий видов ошибки, т.е. расширенные категории, состоя- 
щие из большого числа ошибок, или узкие категории, состоящие лишь из несколь- 
ких ошибок. 


Полные затраты на штатную единицу (ГиПу Вигӣепеа Зіаїї Ваѓе). Затраты на 
одну штатную единицу, включая заработную плату, премии, затраты на инфра- 
структуру и прочие связанные затраты на персонал. 


Золотая сборка, мастер-сборка, сборка общего доступа (Соідеп Виа, Соїд 
Мазіег, СА ВиПа). Сборка или версия, поставляемая заказчикам или устанавливае- 
мая пользователям. Тестовую сборку, предшествующую “золотой” сборке, часто 
называют “золотым” кандидатом (Соїдеп Сапа 1Ча‹е). Если “золотой” кандидат ока- 
зывается качественным, он становится “золотой сборкой”. (СА. означает Сепега] 
Амайабійу (общий доступ), т.е. доступ всем возможным заказчикам и пользовате- 
лям. Гітігед АуаПа Шу (ограниченный доступ) означает бета- или раннюю вер- 
сию для специальных заказчиков.) 


“Золотой” кандидат (Соідеп Сапаійаѓе). Плановая финальная тестовая версия, 
которая при условии, что не будет обнаружено ошибок, требующих исправления, 
становится версией системы, поставляемой пользователям, т.е. “золотой” сборкой. 
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Отдел по работе с персоналом (Нитап Везоигсез Дерагітепі, Регѕоппе] 
Рерагитепі). Группа, отвечающая за 1) поиск сотрудников, контрактников и кон- 
сультантов; 2) выработку политики и процедур управления персоналом; 3) плани- 
рование и управление изменениями в заработной плате и карьерном росте со- 
трудников. 


Жизненный цикл инкрементной системы разработки (Іасгепепкаї Зухет 
Оеуеюршеге ПіЄесусіє). Модель разработки, при которой большой проект разби- 
вается на последовательность шагов; в результате каждого из шагов появляется 
очередная порция функциональности общего перечня требований, зафиксиро- 
ванных в проекте. Требования расставляются в порядке приоритетов и поставля- 
ются в указанном порядке по итогам соответствующего этапа наращивания функ- 
циональности, В некоторых (не во всех) версиях этой модели разработки каждый 
подпроект выполняется в соответствии с мини-У-моделью со своими фазами про- 
ектирования, кодирования и тестирования. Как бы ни был устроен процесс каж- 
дого этапа приращения функциональности, тенденцией является раннее начало 
тестирования с поставкой первой инкрементной тестовой сборки, и далее тести- 
рование продолжается в полном объеме до момента поставки системы или пер- 
вой установки у пользователя. 


Независимая группа тестирования (Іпдерепдепі Тезі Теат). Группа людей, от- 
личная от разработчиков системы, предназначенная для тестирования; в сферу 
ее ответственности входят эффективная проверка и своевременное информиро- 
вание о качестве тестируемой системы. Обычно я рассматриваю эту группу как по- 
ставщика услуг для проектной команды. 


План интеграции (Пиергацоп Ріап). План, определяющий, каким образом раз- 
личные компоненты будут собираться в некоторую логическую многоэтапную по- 
следовательность до тех пор, пока не будет получена система целиком. 


Комплексное тестирование, тестирование продукта (Іпіертайоп Тезипв, 
Ргодисі Теѕііпр). Фаза тестирования, в ходе которой проверяются взаимосвязи и 
интерфейсы между парами и группами компонентов или подсистем системы. 


Ключевые лица, заинтересованные в качестве и тестировании, ключевые за- 
интересованные лица (Кеу Оцаїу апа Тезипа ЭаКеро!4егз, Кеу Зіакепоідеге). 
Сотрудники компании, непосредственно контактирующие с заказчиками, пользо- 
вателями или участвующие в процессе тестирования, а также сотрудники, кото- 
рые хорошо знакомы с техническими деталями системы. 


Библиотека (Іібгагу). См. Репозиторий (Верозиогу) 


Новый сотрудник (Мем Ніге). Лицо, получившее письмо с предложением о заня- 
тии вакантного места и ответившее на него устно или письменно согласием за- 
нять предложенную вакансию. 


Письмо с предложением о занятии вакантного места (Обег Гецег). Письмо из 
компании успешному кандидату с предложением занять вакантное место, вклю- 
чая детальное описание должностных обязанностей, указание фактического раз- 
мера заработной платы и даты начала работы. 


Фаза (Рһаѕе). Логически выделенная часть проекта или подпроекта, состоящая 
из совокупности действий, которые завершаются выпуском продуктов, постав- 
ляемых заказчику. 


Пилотное тестирование (Ріо ТезИпр). Фаза тестирования, на которой система 
подвергается опытной эксплуатации под тщательным наблюдением. Пилотные 
тесты аппаратной части показывают возможности сборочной линии по массово- 
му производству системы. Пилотные тесты программной части показывают воз- 
можности системы по обработке типичных операций реальных пользователей на 
реальной аппаратуре. 
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Тестирование продукта (Ргойисі Теѕііпр). См. Комплексное тестирование 
(10ергайоп Тезіїп5) 


Проект (Ргојесі). Временное предприятие, целью которого является создание 
или поставка некоторого уникального продукта, системы или услуги. Это пред- 
приятие состоит из некоторой последовательности задач, выполняемых группой 
людей при определенных ресурсных и временных ограничениях для передачи 
продукта, системы или услуги некоторому множеству заказчиков или пользовате- 
лей. Диапазон, в котором в течение проекта могут изменяться группа, бюджет, 
график, требования и целевые заказчики и пользователи, может существенно от- 
личаться. 


Качество (ОпаНо). 1. Пригодность для использования. Наличие свойств, атрибу- 
тов и функций, удовлетворяющих ожиданиям заказчиков и пользователей, и от- 
сутствие свойств, атрибутов и функций, неудовлетворяющих ожиданиям заказчи- 
ков и пользователей. 


2. Соответствие требованиям. Наличие свойств, атрибутов и функций, удовлетво- 
ряющих всем установленным требованиям, и отсутствие свойств, атрибутов и 
функций, отклоняющихся от требований. (Данное определение применимо в 
конкретном контексте, в особенности для проектов, выполняемых по контракту.) 


Оценка качества (в отличие от тестирования) (Опаїту Аѕѕџгапсе сопігаѕіеа мі 
Тезипв8). В соответствии со стандартом ТЕЕЕ 610.12-1990 стандартный глоссарий 
терминологии по программированию (ЧЕКЕ Запдага Сіозвзагу ої Ѕоѓуаге 
Епріпеегіпр Теппіпоїору") говорит: оценка качества (ОА) включает в себя “вся- 
кую деятельность, необходимую для обеспечения достаточной уверенности” в ка- 
честве системы и оценку “процесса, с помощью которого [система] разрабатыва- 
лась”, тогда как тестирование состоит из действий, необходимых для 
“обнаружения различий между существующими и требуемыми условиями (оши- 
бок) и оценки... свойств”. Другими словами, оценка качества фокусируется на кор- 
ректности процесса, а тестирование — на установлении качества. 


Риск качества (Омаїйу Віѕк). Потенциальный вид ошибки, способ поведения сис- 
темы, при котором она, вероятно, не соответствует обоснованным ожиданиям ка- 
чества системы, имеющимся у пользователя или заказчика. Заметим, что риск каче- 
ства — это потенциальный, а не обязательный результат с вероятностью больше 
нуля и меньше единицы. 


Рассматривают категории рисков качества. Поскольку виды ошибок также разби- 
ваются на категории, категории рисков качества — это категории категорий по- 
тенциальных дефектов. 


Эталонная система (Кеѓегепсе Ѕуѕќіет). Особый тип тестового оракула, когда суще- 
ствующая система моделирует некоторые или все ожидаемые варианты поведе- 
ния системы, предназначенной для тестирования. 


Регрессия (Кергеѕѕіоп). Система обладает свойством регрессии, если в результа- 
те изменения новая версия системы 5,, содержит ошибку в ранее корректно рабо- 
тавшей функции, т.е. этой ошибки не было в предыдущих версиях, начиная с $, и 
заканчивая 5,. 


Границы регрессионного тестирования (Кергеѕѕіоп Тез Сар). Это разность ме- 
жду тестовым покрытием всего комплекта тестов и тестовым покрытием, кото- 
рое достигается при помощи реально выполненных тестов для данного измене- 
ния или данной версии. Для версии, предоставляемой заказчику, границы 
регрессионного тестирования могут рассматриваться как область, которая в оп- 
ределенной степени не подвергалась проверке в ходе тестирования данной вер- 
сии с применением всего комплекта тестов. 


Регрессионное тестирование (Кергеѕѕіоп Теѕбіпв). Тестирование, предназна- 
ченное для поиска дефектов, вызывающих регрессию, 
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Версия (Кееазе). См. Сборка (Виа) 


Менеджер сборки, инженер сборки (Кееазе Епріпеег, Виа Мапарег, Ѕоџгсе 
Соде Сопігої Епріпеег, Вееазе Мапарег). Специалист, отвечающий за создание 
тестовой версии из исходного кода, данных, метаданных, файлов помощи, \еЪ- 
экранов и прочих объектов, необходимых для сборки системы. 


Менеджер сборки (КеІеаѕе Мапарег). См. Инженер сборки (Вееазе Епріпеег) 
Имя версии (Вееазе Мате). См. Идентификатор сборки (Воћа 1р) 


Репозиторий, библиотека, система управления исходным кодом (Кероѕіќогу, 
Ъгагу, боигсе Соде Сопігої Зузгепі). Программное приложение, обычно рабо- 
тающее на общедоступном сервере. Хранит исходный код, встроенную систему 
оперативной помощи (опіїпе Ре!р), документы НТМІ, аудио- и прочие файлы та- 
ким образом, что после компиляции и ассемблирования создается инсталлируе- 
мый программный продукт. Кроме того, хранит связанные документы, в частно- 
сти планы тестирования, анализ рисков, спецификации требований. 


Коэффициент окупаемости инвестиций (КОИ) (Кешгп оп Іпуезітепі, КОТ). Ве- 
личина, полученная в результате инвестирования в некоторый проект. Коэффи- 
циент окупаемости инвестиций — это финансовая прибыль от инвестиции за вы- 
четом начальных затрат, деленная на начальные затраты: 


КОИ = (Прибыль - Затфаты)/ Затраты 


КОИ обычно умножают на 100% и приводят в процентах. 
Редакция (Кеуіѕіоп). См. Идентификатор сборки (Вођа 10) 
Номер редакции (Кеуізіоп Митђег). См. Идентификатор сборки (Вмі!4 Ір) 


Тестирование на исправность (Запігу Тез). См. Приемочное тестирование (Ѕтоке 
Тез 


Приемочное тестирование, тестирование на исправность (ЅтоКке Тез, 
Запігу Тез). Тестирование, проверяющее, насколько стабильна предлагаемая 
на тестирование версия, чтобы можно было начинать штатное тестирование. 
Обычно это подмножество всего комплекта тестов, как правило, автоматизи- 
рованное, затрагивающее все части системы, по крайней мере, поверхностно. 
Качественные приемочные тесты обычно довольно долго проверяют работу 
системы, чтобы проявились серьезные проблемы надежности и работоспособ- 
ности. Термин "зтоке (е5/" (тест на задымленность) взят из электротехники: 
когда инженер включает цепь, первичный тест проверяет, не дымятся ли ком- 
поненты. 


Инженер исходного кода (Ѕоџгсе Соде Сопіго! Епріпеег). См. Инженер сборки 
(Кеіеаѕе Епріпеег) 


Система управления исходным кодом (Ѕоигсе Соде Сопігої Ѕуѕіет). См. Репози- 
торий (Кероѕікогу) 
Спонсоры (Ѕропѕогѕ). См. Заказчики (Сиѕіотегѕ) 


Заинтересованные (в системе) стороны (Ѕ‹акеһо!йегѕ (іп «Бе ѕуѕсет)). Лица как 
внутри компании, таки вне ее, накоторых влияют в настоящем, повлияют или мо- 
гут повлиять в будущем ход проекта, разрабатываемая система и ее качество. 


Структурное тестирование, тестирование методами “белого ящика” 
(Ѕігосгига] Теѕіѕ, Утие-Вох Теѕіѕ). Тестирование, основанное на внутренних осо- 
бенностях работы системы, обычно апеллирующее к деталям архитектуры, логи- 
ке и данным. 


Заглушка (5їцЬ). Обычно небольшой фрагмент программы, который вставляется 
в код либо заменяет компонент системы, предназначенный для тестирования, 
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чтобы аппроксимировать работу ряда заменяемых с его помощью функций для 
выполнения определенных тестов. 


Экспертиза в предметной области (Ѕиђјесі Мацег Ехрегііѕе). См. Навыки в пред. 
метной области приложения (Арріїсачоп Ротаіп 51115) 


Подпроект (Ѕ$0иЬргојесі). Проект в рамках основного проекта, предоставляющий 
продукты и услуги для основного проекта. Согласно этому определению, тестиро- 
вание, обсуждаемое в этой книге, обычно является подпроектом. Выпуск бухгал- 
терией чеков для оплаты работы участников проекта не является подпроектом, 
поскольку это выходит за пределы контекста проекта. Аудит соответствия доку- 
ментированному процессу, проводимый усилиями сотрудников отдела качества, 
не является ни подпроектом, ни проектом, поскольку он выполняется для нужд 
компании. 


Тестирование подсистем (ЗиЪзуцет Теѕііпе). См. Компонентное тестирование 
(Сотропеп Теѕііпр) 


Система, система, предназначенная для тестирования, разрабатываемая сис- 
тема, система на сопровождении (будет, Ѕуѕіегт ип4ег, Тех, Зумет ипдег 
Реусіортепі, Ѕуѕіет Веіпр Майиатед). Цельная система (программное обеспече- 
ние, аппаратное обеспечение, аппаратно- программное обеспечение ит.д.) сточ- 
ки зрения тестирования. Часто состоит не только из очевидных компонентов. 
Например, в случае офисных приложений в дополнение к исполняемым модулям 
на рабочем месте пользователя могут прибавиться прикладные части, выполняе- 
мые на сервере, которые могут иметь разнообразные интерфейсы с продуктами 
третьих сторон, а также процессы документирования, поставки и обновления, 
онлайновые базы данных и средства поддержки, компоненты аппаратного обес- 
печения, встроенные программы и даже инфраструктура, включая ГАМ, МАМ и 
Интернет. Слово "продукт" до некоторой степени более общий, однако может 
быть некорректно понят как исключительно прикладная программа, предназна- 
ченная для массового рынка. 


Система может быть также системой систем, где каждая система взаимодействует с 
другими системами и зависит от одной и более систем, и все системы существенны 
для работы системы систем. Например, приложение на основе браузера вместе с 
клиентскими программами, меБ-сервером, сервером приложений, сервером баз 
данных есть система систем. 


Наконец, система может представлять собой семейство систем, где каждая система 
взаимодействует с одной или несколькими системами, но зависимости ограниче- 
ны, и система может применяться как самостоятельно, так и винтеграции с други- 
ми системами. Например, М1сгозо_ Осе — это семейство систем программного 
обеспечения. 


Система на сопровождении (Ѕуѕіет Веіпе Маниашеа). См. Система (Ѕуѕсет) 


Жизненный цикл разработки системы (Ѕуѕіет Деусіортепі Іі ѓесусіе). Часть 
жизненного цикла системы, связанная с начальной разработкой системы, начи- 
ная со спецификации и проектирования и заканчивая реализацией, тестировани- 
ем и первичной поставкой. 


Жизненный цикл системы (бузет І іѓесусІе). Все множество действий, которые 
имеют место в ходе разработки, поставки, использования и устаревания системы, 
начиная с исходной спецификации и проектирования, далее включая реализа- 
цию, тестирование, поддержку, сопровождение и заканчивая остановкой и выво- 
дом системы из эксплуатации. 


Системное тестирование (Зузіега Тезіїпр). Фаза тестирования, на которой про- 
веряется поведение системы как в целом, так и в частностях, и ее функциональ- 
ность. | 


Разрабатываемая система (Ѕуѕіет ип4ег Деуеіортепі). См. Система (Ѕуѕіет) 
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Система, предназначенная для тестирования (Ѕуѕіеш ип4ег Тез). См. Система 
(Зумет) 


Задача (ТазК). Рабочие элементы активности, которые являются логически по- 
следовательными множествами действий, включающих в себя соответствующие 
наборы умений и навыков. 


Технические умения и навыки (Тесіпіса! $115). Способность применять опре- 
деленные методы и инструменты, которые планируется использовать при созда- 
нии системы, например, языки программирования или серверную и сетевую ар- 


хитектуру. 


Артефакты тестирования (Тез: Аг(іҒасіѕ). Поведение, которое возникает из-за 
искусственной природы тестовой среды или из-за того, что процесс тестирова- 
ния отклоняется от потенциальных действий системы в реальных условиях; не- 
верное поведение или некорректные результаты, полученные с помощью систе- 
мы тестирования. 


Тестовый сценарий (Тез Саѕе). Последовательность шагов, состоящих из дейст- 
вий, которые необходимо выполнить при помощи системы, предназначенной для 
тестирования. (Эти шаги обычно называют тестовой процедурой или тестовым скрит- 
том.) Такого рода действия обычно увязывают с некоторым набором данных (зара- 
нее загруженным или вводимым в процессе выполнения сценария). Комбинация 
выполняемых действий и данных, передаваемых системе в процессе выполнения 
теста, приводит систему к некоторому тестовому состоянию. В тестовом состоянии 
система выдает результаты, которые можно сравнить с ожидаемыми, т.е. оценить 
качество в данном тестовом состоянии. Такие действия могут выполняться после- 
довательно, параллельно или в различных вариациях. 


Тестовое состояние (Тез: Сопӣійоп). Состояние системы, выходные данные, ре- 
зультат или условие, порождаемые выполнением тестового сценария, преимуще- 
ственно интересные с точки зрения оценки качества системы. | 


Тестовое покрытие (Тез: Соуегаре). 1. Структурное: степень покрытия тестами 
структуры - кода, подсистем или компонентов - в системе, предназначенной для 
тестирования. | 


2. Поведенческое: степень покрытия тестами поведения -- рисков качества, режи- 
мов работы, функций, активностей и прочего применения — системы, предназна- 
ченной для тестирования. 


Тестовый цикл (Тез Сусіє). Выполнение некоторого подмножества тестов для 
одной, определенной тестовой сборки. 


Тестовые данные (Тез ага). Набор входных данных, который используется в 
тестовом сценарии. Данные вводятся либо при помощи пользовательского ин- 
терфейса, либо из хранимого файла, либо из другой взаимодействующей систе- 
мы. 


Тестировщик, инженер тестирования (Тез Епріпеег). Сотрудник группы тести- 
рования, обученный, обладающий навыками и опытом во всех областях тестиро- 
вания (планирование, проектирование, резлизация и выполнение), а также обла- 
дающий определенными навыками в проведении технической экспертизы и 
знанием прикладной области. (В некоторых штатах и странах лица, чей титул 
включает в себя слово “инженер”, должны иметь профессиональную лицензию 
(диплом).) 


Тестовая среда (Тех Епуігоптепі). Аппаратное и программное обеспечение, 
оборудование и помещения, необходимые для проведения тестирования. 


Пропуск при тестировании (Те5( Еѕсаре). Любая ошибка, которая могла быть об- 
наружена при тестировании, но была пропущена. Термин часто применяют к 
ошибкам, обнаруженным на фазах, 
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следующих за тестированием, хотя они должны были быть найдены на предыду- 
щей фазе. 


Процесс выполнения тестов (Тез: Ехесиќіоп Ргосез5). Методы, при помощи ко- 
торых тестировщики и другие ключевые участники процесса тестирования ис- 
пользуют тестовые программы в тестовой среде. 


Степень детализации при тестировании (Тезі Сгапиіагігу). Точность нацелива- 
ния теста. Точные (бпе-ртаіпе) тесты позволяют тестировщику проверить низ- 
коуровневые компоненты, особенно реализации; статические и структурные тес- 
ты являются точными. Грубые (соагзе-ртате4) тесты предоставляют 
тестировщику информацию об общей работе системы и требованиях; поведенче- 
ские тесты и тесты для опытной эксплуатации являются грубыми. 


Уровень тестирования (Тез Г.еуе!). См. Фаза тестирования (Тез РВазе). 


Инструменты управления тестированием (Тез: Мапаретепи Тооіз). Инстру- 
менты, управляющие объектами систем тестирования и их результатами. Клас- 
сическими примерами являются системы управления дефектами и тестами. Бо- 
лее продвинутые системы предоставляют полномасштабные средства для 
проектирования, реализации и выполнения тестов. Такие системы обычно ин- 
тегрированы с инструментами тестирования, хотя иногда эти дополнительные 
возможности ограничивают полезность инструментария для тестов, поддержи- 
ваемых инструментом тестирования. 


Тестовый оракул (Тезі Огасіє). Система, метод или методика для предсказания 
или оценки корректности поведения системы, предназначенной для тестирова- 
ния, в определенных условиях. 


Тестовый раунд (Тез Раз). Выполнение тестов, определенных для данной фазы 
тестирования. 


Фаза тестирования, уровень тестирования (Тез Рһаѕе, Тез Геуе!). Выделяемая 
совокупность действий тестирования, адресованная фиксированной группе рис- 
ков качества, например: компонентное тестирование, комплексное тестирова- 
ние, системное тестирование, приемо-сдаточные испытания. (Я предпочитаю ис- 
пользовать слово “фаза”, тогда как другие говорят “уровень”.) 


Специалист-тестировщик (Тезі Ргоѓеѕѕіопа]). См. Тестировщик (Теѕгег) 
Тестовая версия (Тезі Ве|еазе). См. Сборка (Виі!4) 


Тестовый скрипт (Тез Зсгірі). Описание того, как выполнять один и более тесто- 
вых сценариев при проведении тестирования вручную. Часто называют тестовой 
процедурой. При автоматизированном тестировании говорят о соответствую- 
щих последовательностях команд, выполняемых компьютером. 


Комплект тестов (Тез Ѕег). Все наборы тестов, которые группа тестирования 
планирует выполнить в течение данной фазы (или уровня) тестирования. 


Младший тестировщик (Теѕі Зресіаїзс). См. Лаборант-тестифовщик (Тез 
Тесһпісіап) 


Стратегия тестирования (Тез Ѕігаїеру). Совокупность выбранных подходов и 
решений, вытекающих из целей и задач подпроекта тестирования и группы тес- 
тирования. Целью обычно является эффективное и качественное тестирование, 
а стратегия — это общие правила и принципы, способствующие достижению 
цели. Тактика тестирования - это частные правила, методики, процессы и спосо- 
бы проведения тестирования. 


Подпроект тестирования (Тез Ѕирргојесі). Совокупность задач, необходимых 
для предоставления услуг тестирования и информирования о качестве и ходе тес- 
тирования заинтересованных лиц проекта, а также содействие проектной коман- 
де вуправлении рисками качества. 
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Набор тестов (Тез бийе). Совокупность логически связанных тестовых сценари- 
ев. Те или иные тестовые сценарии могут содержаться в нескольких наборах тес- 
тов. 


Лаборант-тестировщик, младший тестировщик (Тезё Тесһпісіап, Тея 
Зресіаїзг). Специалист по тестированию, менее квалифицированный, менее об- 
разованный и менее опытный, чем инженер-тестировщик, хотя бы в одном из 
критических направлений (тестирование, предметная область или технологии). 
Лаборанты- тестировщики обычно занимаются выполнением тестовых скриптов 
вручную и другими очевидными задачами своего уровня. См. также Тестировщик 
(Тезгег) 


Тестировщик, специалист-тестировщик (Тецег, Тезі Ргоїезвіопа!). Лицо, вы- 
полняющее задачи, относящиеся ктестированию. Человек, работающий в группе 
тестирования постоянно или временно в качестве сотрудника, контрактника или 
консультанта. Я использую этот термин как аналог понятия “разработчик” или 
“программист” в группе разработки. 


Тестирование (Тезііпе). Функционально это процесс оценки качества системы, 
предоставления услуг и информации, позволяющий компании управлять риска- 
ми качества системы. Организационно это группа специалистов, предоставляю- 
щая данныеуслуги и информационные продукты для проекта, в котором она заня- 
та. 


Умения и навыки тестирования (Тезипр $К115). Квалификационные способно- 
сти, относящиеся к выполнению задач тестирования, например к разработке ка- 
чественных тестовых сценариев и написанию подробных отчетов о дефектах. 


Инструменты тестирования (Тезипр Тооіз). Любая система, способствующая 
выполнению задач тестирования, таких как проектирование, реализация, вери- 
фикация, выполнение, измерение и интерпретация тестовых сценариев, тесто- 
вых данных и результатов тестирования. В качестве инструментов могут высту- 
пать таблицы, шаблоны, базы данных, комплексные заказные утилиты 
собственной разработки и коммерческие системы. Инструменты бывают комби- 
нированные и интегрированные. Некоторые инструменты, в частности системы 
захвата / воспроизведения и утилиты покрытия кода, разрабатываются сразу как 
инструменты тестирования, другие - отладчики, языки скриптов — лишь исполь- 
зуются в этом качестве. 


Средства тестирования (Тезгмаге). Тестовые сценарии, тестовые данные, тесто- 
вые скрипты, инструменты тестирования, протоколы тестирования, отчеты о 
тестировании, а также соответствующие руководства пользователя и документа- 
ЦИЯ. 


Модульное тестирование (Опи Тезііпе). Тестирование небольшого элемента 
или модуля системы, 


Пользовательское приемочное тестирование (Оѕег Ассеріапсе Теѕііпе). См. 
Приемо-сдаточные испытания (Ассергапсе ТезИп8) 


Пользователи (Оѕегѕ). Люди, которые работали и, возможно, будут работать с 
системой, а также люди, применяющие результаты работы системы. Иногда поль- 
зователи являются заказчиками системы, но не всегда. 


У-модель (У Моде!). Вариация каскадной модели, в которой задачи разработки 
идут сверху вниз по левой стороне буквы У, а задачи тестирования -- вверх по пра- 
вой стороне буквы У. Внутри У проводятся горизонтальные линии, показываю- 
щие, как результаты каждой из фаз разработки влияют на развитие системы тес- 
тирования на каждой из фаз тестирования. Модель базируется на том, что 
приемо- сдаточные испытания основываются, прежде всего, на требованиях, сис- 
темное тестирование — на требованиях и архитектуре, комплексное тестирова- 
ние — на требованиях, архитектуре и интерфейсах, а компонентное тестирова- 
ние - на требованиях, архитектуре, интерфейсах и алгоритмах. 
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Версия (Уегзіоп). См. Идентификатор сборки (Вийа 1р) 
Номер версии (Уегѕіоп МишЪег). См. Идентификатор сборки (Виі!4 Ір) 


Жизненный цикл каскадной модели разработки системы (У’мегаП Зузет 
Оеуеюртеги ГМесуе). Модель разработки, в которой группа разработки прохо- 
дит серию последовательных фаз в процессе создания системы. Сначала группа 
определяет требования, затем проектирует систему и наконец реализует ее в 
коде. Как только код системы готов, система проходит через последовательность 
фаз тестирования, начиная с модульного или компонентного тестирования, за- 
тем комплексное тестирование и наконец системное тестирование. (В случае кон- 
трактной разработки или разработки для внутреннего применения часто после 
системного тестирования проводятся приемо-сдаточные испытания.) Вариации 
этого подхода допускают наложение фаз, не требуя завершения каждой из фаз пе- 
ред началом следующей. 


Тестирование методами “белого ящика" (У/Піге-Вох Тезі5). См. Структурное тес 
тифованиє (Зігастита! Те518) 


БИБЛИОГРАФИЯ 


Адатз, Ооџеїаѕ. Тйе Ниси ег; Сийде іо ће Сщаху. Мем УотК: Вайапипе, 1995. 


Айзоп, Аппа. "Меапіпрїці Меїтісз". бойшате Тезійпр апа Оиаійу Епріпеєтіпо, Моїйте 3, 
Івззие 3 (Мау/ Типе 2001): равеѕ 38 - 45. 


Васі, Јатеѕ. “Ехр]огагогу Теѕіпр апа {Ве Р!аппіпр Му". ум з скупліпдз.со. 
Васі, Гатез. “Тез: АлющтаНоп ЗпаКе-ой”. муги.зацівбсе.сот. 
Вагец, Вобегі. “Ромег Теѕйпр”. Ргосееаїпру орійе КІЛЬ Іпієтайопа! Оша гек Еиторе. 


Веігег, Вогіѕ. ВІаск-Вох Тезійпр. Мем ҮогКк: М1еу, 1995. Есть русский перевод: Бейзер Б. 
Тестирование черного ящика: Технологии функционального тестирования про- 
граммного обеспечения и систем. - СПб: Питер, 2004. 


Веігег, Вогіѕ. “боймаге 15 ОШегепг”.. боймате Кеѕеагсһ'ѕ ОпаШу Тесһпідиеѕ 
Мемзіецег агсһіуезѕ. уи\.зой.сот/Мемз/ОТМ-ОпНпе/атарго 1.5, 
мути. зо. сот/ Мем$/ОТМ-ОпПпе/ ататаудіБиті, мми.5оЁ.сот/Мемз/ ОТМ- 
ОпПпе/аеип01.Вит. 


Вешег, Вогіѕ. 5о/їшате Зуяет Тезійпр апа Оиа@у Аззитатсе. Мем ХогК: ПцегпаНопа! 
Тһотѕоп Сошрщег Ргез5, 1996. 


Вешег, Вогіѕ. бойшате Тезійпр Тесйтадиез, З5есопа Еайіоп. Мем Үотк: Уап М№оѕігапа 
Кеіпһо!а, 1990. 


Вегпѕѓеіп, Реег. Арат ће Сойѕ. Мем УогК: М/їеу, 1996. 
Віпаег, Кобегі. Тезійпр Ођјесі-Огіетіеа Зойшате. Возгоп: Аддізоп-У/езіеу, 1999. 


ВіасК, Вех. "Стіціса! Зоймаге Тезипв Ргосеззез”. /оиттаі оў Ѕоўїшате Тезійпр Ртојгѕзіотаіз, 
Уоіџоте 1, 1551е 1 (Маг 2000). 


ВіасК, Кех. “ЕНесцуе Тез Згагиз Керогіпр”. боЙшате Тезійпр апа Оиаійу Епріпеетіпр, 
Уоште 2, Іѕѕие 2 (Маг/Арг 2000). 


ВІаск, Кех. “Еасіогѕ Тћа ЇпПиєпсе Тез ЕзитаНоп”, мм з іскутіпдз.сот. 
ВіасК, Кех. “Ромг Мауѕ Таѕііпе А4д5 Уаіџе”. Ргосее@трз оће Еито5 ТАВ 2002 Сопјетепсе. 
ВіасК, Кех. Мапаріпр 1ће Тезійпр Ртосеѕѕ, 5есопа Едйіоп. Мем Уогк: МЛіеу, 2002. 


Віаск, Кех. "Зіор Реѕігоуіпр Му Теаш мі Ваа МВОз: А Мапарег'ѕ Мем Үеагѕ 
Кезоїшіоп", ими. зисКупии 4. сот. 


ВЙаск, Кех. "Тезі ЕзитаНоп”. 5о/їшате Тезійпр апа Оиаїйу Кпріпеегіпр, УоТате 4, Іззие 6 
(Моу/Бес 2002). 


Библиография 


Віаск, Вех. “Тће Тез Ехесийоп Ргосеѕѕ”. /оцтпаї оў Зо/їшате Тезіїпр Ргореяопаб, 
Моїште 1, Іѕѕџе 3 (Ѕер 2000). 


ВіасК, Вех. “Тез Ве!еазе Ргосез5”. /оитаї оў 5о/їшате Тезійпр Ро/е5зіопаіз, Уоїате 1, 
Іѕѕџе 2 (Јипе 2000). 


Віаск, Вех, апа Стер КирасгКомѕКі, “Міѕѕіоп Майе РоѕѕіЫе”. Зо/їшате Теѕііпо апа 
Оиаійу Епріпеєгіпр, Уоте 4, Іѕѕџе 4 (Јиу/Аџс 2002). 


Воерш, Вагту. Ѕојѓшате Епріпеетіпс Есопотіс5. Ргепіісе-На!! РТК, 1982. 


Вгоокз, Егеденск Р., Її. Те Муйисаї Мап-Мотй. Веадіпр, Маз5.: Аадіѕоп- У/езіеу, 
1975. 


Вгоокз, Егедегіск Р., Јг. Тһе Муса Мат.Мопій, 5есопа Ейійоп. Веа@т8, Маз5.: 
Аддїзоп-М/езіеу, 1995. Есть русский перевод: Брукс Ф. Мифический человеко- 
месяц, или Как создаются программные системы. — М.: Символ-Плюс, 2001. 


ВиПоск, Јатеѕ. “Саісшайпе (ће Уаше об Тезіпя". 5о/їшате Тейпе апа Оиаййу 
Епріпеетіпр, Уоїцте 2, Іѕѕие З (Мау /Јипе 2000): рареѕ 56 — 62. 


Вима1да, Напз. “боар Орега Теѕіпр”. Росеедпря ор ће 5ТАВ Казі 2000 Сопјетепсе. 
СатрапеПа, Јаск, ей. Ритсё 4х о} Она Собіз. МіїмацКее, Міѕс.: АЗО, Омаїну Ргез5, 
1999. 


Сегуапіез, Міриеї. Доп Ошхое. Мем УогК: Реприп, 2003. 


Соћп, Ме. “А Меазиге4 Кезропзе”. 5о/їшате Тезійпр аті Оцаїйу Епріпеегіпр, Уоїате 4, 
Іззце 5 (Зер/Осе 2002). 


СоПага, Во55. “Тез Реѕірп: Рреуеіоріпр Тез! Сазез гот Оѕе Сазез”. ЗоДшате Тезійпрата 
Оиаїйу Епріпеетіпр, Моїите 1, Іззце 4 (\4у/Ацв 1999). 


Сореапа, І ее. "Ехріотаїоту Ріаппіпр". мига .5іскутіпаѕ.сот. 
Соре!ап4, І ее. Мазіетіпр Ѕоўћшате Тезі Реѕірт. Еог!ћсотіпу. 
Сореїіапа, І ее. “МТеп Нершр Ооеѕп' Не!р”. муг.ѕіскутіпаѕ.сот. 


Сгаір, Віск, апа $еѓап ЈаѕкіеЇ. узетайс Зойшате Теѕііпо. Мем Үогк: Атїесһ Ноџѕе, 
2002. 


СгозЪу, Рр. Оцай% [5 Ктєе: Тће Ап оў Макіпр Оцаїйу Сепат. Мем Уогк: МсСтам-НІШ, 
1979. 


Де Јаерег, Регег. “Тһе Віз іп Віѕк Мапаретепі”. бо/їшате ТейтЕ апа Оиаійу 
ЕКпріпеетіпр, Уоїате 3, Іѕѕџе 4 (Јшу/А хе 2001): рареѕ 63 — 64. 


реМагсо, Тот. Т/е Беаайте. Мем УогК: Оогѕеі Ноцзе, 1998. 


ОеМагсо, Тот, апа Тіт Изчег. Реорієшате, 5есопа Еййіоп. Мем Уогк: Оогѕеє Ноџиѕе, 
1999. 


ЮеМагаіѕ, Сһгіѕ. “Регзреснуез от а Тез: Мапарег”. боДшате Тезіїпр апа Фиаййу 
Епріпеетіпр, МоГатае 2, Іѕѕие 5 (Зер/ Осі2000). 


ОДетіпе, М. Е. Ои: оў Ст55. Во5соп: МІТ Ргезз, 2000. 


РоБЫтз, Јатпеѕ. боЙшате Оиаїйу Азѕитатсе апа Еощиайоп. Міїмацкеє, М/їзс: АЅО 
Оиаїну Ргезз, 1990. 


га ск, Койдег. Везі Ргасіісез јот Ѕоўћшате Тезійпр. Мем Хогі: Догзе! Ноџѕе, 2003. 


Огабіск, ВоЧрег. “Сгомћ ої Магигіку іп (һе Тезііпе Ргосеѕѕ”. мугпи.5О0ЙЦезі. 
огр /агіісіеѕ /гагађісКЗ.Һт. 

Ргабіск, Войрег. “Мойеіпе Фе Гога! ће Теѕіпе Ргосеѕѕ”. бо/їшате ОА Марахіпе, 
Моіште 2, Митфег 2: рареѕ 20 — 38. 


ОгаЫск, Коддег. “Оп-Тгаск Кедџігетепіѕ”. 5о/їшате Теѕзйпе ата Оша Епріпеегіпр, 
Уоіитпе 1, Іѕѕие 3. АуаЙаЫе аг ум 5 і Скутіпадз.сот. 


Библиография 541 


Огабіск, Водрег. "А Ргосеѕѕ Моде! ої Зоймаге ОцаНёу Аззигапсе/Зоймаге ОцаШЩу 
Кпріпеегіпр”. 5о/їшате Оцаїйу Ргојеѕзіотаї, Моате 2, Їззце 4 (Ѕер 2000): равеѕ 20—38. 


Ризі, ЕЁчеде. “Ог‹Һоропау Ѕреакіпр”. 5о/їшате Тейти апа Оиайу Епріпеєгіпо, 
Моїште 3, Іѕѕџе 5 (Зер/ Оси 2001). 


Дизіп, Кібіеде, Је Ваѕһка, апа Јоһп Рам! Ашотаиеа Зойшате Тезіїпр. Воѕіоп: 
Аадіѕоп-Меѕ1еу, 1999. Есть русский перевод: Элфрид Дастин, Джефф Рэшка, Джон 
Пол. Автоматизированное тестирование программного обеспечения. Внедрение, 
управление и эксплуатация. — М.: Лори, 2003. 


Пуез, Тіт, “Тгаскіпр Зеуегиу”. боДшате Тезітр апа Оцаїйу Епріпеєтіпр, Уоіоте 1, Іѕѕие 
2 (Маг/Арг 1999). 


Епѕмогіћ, Раїггісіа. Тйе Ассійепіа! Ргојесі Мапарет. Мем Үогк: МПеу, 2001. 


Еемѕѓег, МагК, апа рогоу Сгаһат. бо/їшате Тез Аиіотайоп. Нагіом, ОК: Айаіѕоп- 
У/еѕ1еу, 1999. 


Сагапег, Кођегї. “Кеѕојуіпе (ће Ргосеѕѕ Рагадох". Ошаййу Ргортез5, Уоіоте 34, Іѕѕие 3 
(Маг 2001): радез 51 — 59. 


СИЬгеа®, Кобегі. Иптіпр аі Руојесі Мапаретепі. Мем Үогїк: УШеу, 1986. 


Тһе Сие іо ће Рго)єсі Мапарєтепі Воду оў Кпошіейре, 2000 Ейійіоп. Меупомт Зацаге, 
Репп.: Ргојес Мапарегпепі тзйиие, 2000. 


Наадеп, Віка. "Стедібіе Езгітакіоп бог Эта| Ргојесіѕ”. Зойшате Оиаїйу Ргтојезѕіопаі, 
УМоїате 3, Іѕѕце 2 (Маг 2001): рарез 7 — 11. 


Непагіскзоп, ЕіѕаБеѓћ. “Моге Теѕііпр, Могѕе Оцаїсу". мум.диаПеуигее.сот. 
Нее], ВІЙ. Те Сотріеіе Сиіае іо Ѕоўёшате Тезійпр. Мем УогК: Меу-ОЕР, 1988. 


Ноҝ#тал, Роиріаз. “Оѕіпр Огасез іп Теѕіпр Аџшотабйоп”. муу.ѕобмагедиаііу- 
теіһоазѕ.сот. 


Ноуег, Кођегт, апа Вгооке Ноуег. "М/рБак Із Омаїту?" Оиаїйу Ргортеѕѕ, Моите 34, Іѕѕие 
7 (ау 2001): равез 52 - 62. 


Нипрігеу, Макв. Іпітодисійт іо 1е Ретѕопа! Зойшате Руосез5. Веа те, Мазз.: Аддізоп- 
М/езієу, 1997. 


Пеце, КаЩееп, апа бизап Вагіїей. “Езитания Тезгег го Оеуеіорег Вагіоз (ог Мо)”. 
Ртосеейітрѕ оў Ше ЗТАК УКезі Сопјгтепсе 2001. Огапре Рагк, Кіа: бЗоймаге ОпаШу 
Епбіпеегіпе, 2001. 


Іпіегпайопа! Згапдагдє Отрапігаціоп. І5О/ТЕС 9126:1991 (Е). Сепеуа, Ѕиуісгетіапа: 
ІЅО ЛЕС Соругірћ Осе, 1991. 


Івпікама, Каоги, Сийде іо Опаїйу Сопітої. ТоКуо: Аѕіап Ргодисцуйу Огваптаноп, 1982. 
Їаїоге, Рапкој. СММ іп Руасійсе. Воѕгоп: А4дізоп-У/єзієу, 1999. 


Јоһпѕоп, Кагеп. “Рейуейия Опмеісопге Мемз го Оеуеюрегз”. боЙшат Теѕйпр апа 
Оиаїйу Епріпеєгіпр, Моїате 4, [554е 5 (Зер/Осі 2002). 


Јоһпѕоп, Рау]. ИиеЦесша!5. Мем УотК: Нагрег апа Ком, 1988. 
Јопеѕ, Т. Сарегз. Езйтайтр бойшате Созіз. Мем Уогі: МсСгам-НіП, 1995. 
Лигап, Ј. М. дал оп Рапттё рот Оиаїйу. Мем УогК: Егее Ргеѕѕ, 1988. 


Лагап, ]. М., апа Егапк Ступа, ейѕ. Оцаїйу Сопітої Напафоок, Еоитіћ Едйіоп. Мем УогК: 
Мебтам-НІЇ, 1988. 


Кап, Ѕіерһеп. Мес; апа Модеё т 5о/їшате Опаїйу Епріпеетіпр, 5есопа Еайіст. Возіоп: 
АааіѕопМеѕ1еу, 2003. 


Капег, Сет. “Агсһіесіџгеѕ об Тезі Алютаноп”. мули Капег.сот. 
Капег, Сет. “Сет Капег оп Ве фа шв Ѕобмаге Мебгісѕ”. муги.з іскупіп дв. сот. 


542 


Библиография 


Капег, Сет. "Меазигетепі об'їБе Ехѓепі ої ТезИп8”. уму.Капег.сот. 
Капег, Сети. “Ома у Собі Апаїубів: Вепебіз апа Е1зК5”. мими Капег.сот. 


Капег, Сет. "Весгийіпє бой\жаге Тезчегз”. ммуг5ітарагіпе.сот / доситепів / 
$=751/34119912Е/9912рит. 


Капег, Сет, |атез Васі, апа Вге! Решіспога. [255075 Геаттей т ЕА Тезітр. Мем 
Үогк: МЩеу, 2001. 


Капег, Сет, Јаск Каїк, апа Нипр Опос М№еџуеп. Тёйте Сотршет 5о/їшате, Зесота 
Ейійіоп. Мем Уогк: Пиегпанопа! Тћотѕоп Сотриќег Ргезз, 1993. Есть русский пере- 
вод: Канер Сэм и др. Тестирование программного обеспечения. — Киев: Диасофт, 


2000. 
Капег, Сет, ап Рау Ре. Вай Зо/йшате. Мем Уогк: УШеу, 1998. 


Каззе, Тип, апа Раїгісіа МсОиаїй. “боймаге СопЯригаНоп Мапаретепі ог Ргојесі 
Геаег5”. 5о/йшате Оиаійу Ро/є55іопа!, Хоїите 2, Іѕѕие 4 (Ѕер 2000): рареѕ 8 — 19. 


Ки, Еа. бойшате Тезійпр т іће Ве Мотій. Нагіом, ОК; Аааіѕоп-Меѕ1еу, 1995. 


Коотеп, Тип, апа Магии Ро]. Тезі Ргосез; Гтртооететі. Нагіом, ОК: Аадіѕоп-Меѕ1еу, 
1999. 


Магсіпіак, оба, ей. Епсусіорейїа оў 50/їшате Епріпеетіпр, 5есопа Еайіоп. Мем Үотк: УШеу, 
2001. 


Магіск, Вгіап. "Сіаззіс Теѕіпр Мізгакез". мим лезіпр.сот. 
Магіск, Вгіап. Сғаў ор5о/їшате Тезійпр. Сррег Ѕайа1е Віуег, М): Ргепіісе На1ї, 1995. 
Магіск, Вгіап. "Мем Модеїз бог Тез реуеїортепі". ммм езИп8.сот. 


МсСіпіс, Коп. “Гоа@ Регѓогтапсе ап Зсаїабійсу Теѕііпр СһаПепреѕ іп Е- 
Соттегсе”. бо/їшате Оцаїйу, Матіег 2 (М/іпіег 2001): рабез 1 апа 3 - 5. 


МсСоппей, Ѕ‹еуе. АДег іће Со Визй. Кедтопа, Маѕһ.: М1сгозой Ргез5, 1999. | 


МсСоппеП, ${еуе. боДшате Руојесі Зитоиа Сие. Ведтопа, М/азр.: Масгозой Ргез5, 
1998. 


Мсрегтоѓ, Кот, Ваутопа Міки]ак, апа М1свае! Веайгерага. Тһе Ваѕісѕ оў ЕМЕА. 
Рогапа, Оге: Ргодиснуцу, 1996. 


Мепдопса, Їобп, апа Кобегі ГлпеБегрег. “Мефо4о]ояу аз Коаа Кі: Тһе Оесаде- 
Гоп Аззації оп Омайу Аззигапсе”. бо/їшате Ошаййу, МатЪег 3 (Ѕргіпр 2001), равеѕ 1, 
3, апа 4. 


Мооге, Сеойгеу. Стоѕѕіпр іЛе Сһаѕт, Зесопа Еайіот. Мем Үогк: Нагрег СоШпѕ, 1999. 


Муегз, Сіепбога. Тһе Аті о 5о/їшате Тезіїпр. Мем Үогїк: УШеу, 1979. Есть русский пере- 
вод: Майерс Г. Искусство тестирования программ. — М., Финансы и статистика, 
1981. 


Меџтапп, Регег. Сотриіет-Кеіаіеа Кізіз. Веадіпя, МА: Аааіѕоп-Меѕ1еу, 1995. 
Мемуеп, Нипб. Тейтр Арріїсаййт оп фе Иер. Мем Хогк: УТеу, 2000. 

Місізеп, ]аКоЪ. Сзафійу Епріпеєтітр. Зап Егапсізсо: Могвап Кайітапо Рибіїзреге, 
1993. 

№151 Уазираги. “Кеѕоигсе Рас Теѕііпр: А Егате\могК ог Реѕірп об Ѕуѕіет Тез(іпе". 
Зо/їшате Оиа у Ргојеѕѕіопаі, Моїите 3, Іѕѕие 3 (Тапе 2001). 

Мупап, Моеї. “Озтя Мопкеу Тез Тооіз". Зо/їшате Тезійпо апі Ошийу Епріпеетітр, 
Уосіште 2, Іѕѕие 1 (Јар /ЕеЬ 2000). 


Раш К, МагК С., СБайез У. УеЪег, Ві] Сиг, апа Магу Већ Сһгіѕѕіѕ. Т^е Сара у 
Манту Моагі. Веадіпе, Мазз.: А4дїзоп-У/єзіеу, 1995. 


Библиография 543 


Раупе, ]еЁ. “Опа су Меесѕ е СЕО”. бо/їшате Тезітр апа Оиаїйу Епріпеєтіпр, Уоїате 1, 
Іѕѕие 3 (Мау /Јоипе 1999). 


Решту, Юемаупе, апа Сай Каіѕег. "Обіесі"Огіепіед Ргортатз апа Тезііпр". 
сігеѕеег.пј.пес.сот /реггу90објесіогіепгей.Һеті. 


Реггу, МіШат, апа Вапааії Вісе. бигойлтр йе Тор Теп СВайєпрез оў Ѕоўїшате Тезійпр. Мем 
Үогк: Вогзе! Ноизе, 1997. 


Регегзеп, Епік. “Ѕтпагіег Тезиов Оѕіпу (ће 80/20 Кије”. Руосееаіпоз оў ће ЗТАЕ Мезі 
2002 Сопјётепсе. 


Ріаго. Те Тиіаі апа Реаіћ оў Ѕостаіеѕ, Тата Еайіст. Мем Уогк: Наскеи Рибізріпо, 2001. 


Ро], Магіп, её а]. 5о/їшате Теѕйпр: А Сиіде іо ће Т-МАР Арртоасћ. Возіоп: Аддізоп- 
Ұеѕ1еу, 2001. 


Ргеззтап, Ворег. 5о/їшате Епріпеегіто: А Ргасійіотет'ѕ Арртоасћ, Еоитћ Ейійоп. Мем 
Уогі: МсОтам-НІЇ, 1997. 


Опцепип, Сеой. “Реоріе 51115, Іпсіадіпе Пе Веуієм/ аз а Тез Тесплідие". Рео/є5зістаї 
Теяет, Моїате 2, Іѕѕџе 2 (Јопе 2001): рареѕ 42 — 43. 


Казка, Је. "Тезі. ЕНогі Езатацоп”. /оитпаї оў 5о/їшате Тезійте Рго/є55ідпаіз, Уоите 2, 
15зще 1 (Маг 2001): равеѕ 3 — 7 апа 38. 


Возепреге, Гіпда, апа Гамгепсе Нуаи. “Оеуеюритв а Зиссезз Меїгіс5 Ргортат". 
затс.ряїс.паза.роу/ 5аррогі /іпаех.һті. 


Коїтап, ]оваппа. “Нав Тесппіса! Реоріе: А Сие со Нігіпр (ће Кір Реоріе юг 
е Тоб". му го тлап.сот. 


ВоШтап, |обаппа. “Тһе Іпбиепіаї Тез Мапавег”. 5о/їшате Тезйпр апа Оиаїйу 
Епріпегтіпр, Чоїцте 2, Іѕѕие 2 (Маг /Арг 2000). 


Ко!тап, Јоћһаппа. "є Ререпаӣѕ: Рресідйіпе оп «Бе Соггесе Кано ої Реуеіорегѕ (о 
Теѕгет”. мули гофитап. сот. 


Кота, Јоһаппа. “Мапарег Неа! Тһуѕе1?. уму го тат. сот. 


Когтап, Јоһаппа. “Ве]еазе Сгігетіа". оЙшате Тезійпр апа Оша у Епріпеєгіпр, Уоїате 
4, Іззце 2 (Маг/Арг 2002). 


Коштап, Їобаппа. “Тезип8 іп Ше ОагК”. бойшате Техійпр апі Оиаійу Епріпеєтіпр, 
Моїате 1, Іѕѕџе 2 (Маг/Арг 1999). 


ВиЫ, апес. Тйе Сотршет Сопѕиіаті'ѕ Силае. Мем УотК: М1]еу, 1997. 

Забоиит, Кобегі. “Ат Үоџг Ѕегуісе”. 5о/їшате Теѕііпр апа ди у Епріпеетіпо, Моїате 3, 
Іѕѕие 3 (Мау /Јопе 2001): рареѕ 46 — 52. 

Забоийтіп, Кођегі. І Ат а Вир. ЗеН-рибПзВеа, 1999. 

Ѕабоигіп, Кобегі, апа Кіт Оау15. "Ехріогіпя, Юіѕсоуегіпр апа Ехіегтіпаііпр Вис 
Сшеегз іп МеЬ Аррісабіопѕ”. ууу. ап! Рив.сопа. 


5сптзацсі, СБапез. 150 9000 јот Зо/їшате Реоеіоретѕ. МіїмацКее, Міѕс.: АЅО ОпаШу 
Ргезз, 1994. 


Ѕсһпідг, Міспає! Е. С. Гтріетепііпр іће ТЕБЕ $ойиюте Епріпеєгіпр Зат4ата$. 
Іпазапароїїз, Іра.: ЗАМ$ РиЫіѕһіпе, 2000. 

Ѕіттопѕ, Егік. “Тће Нитап 51де об Ві5К". Ргосеейтрз оГійе Еійеетій риетпайопа Гпіетпеі 
апа Ѕоўёшате Оцайу УРее 2002. 


51ацрћќег, бапага, Рауій Нацег, апа Мауџгат Кгіѕһпап. "Куаїцаціпу (һе Соѕі ої 
Зобугаге Опа”. Соттипісайопз о} ле АСМ, Уоате 41, МитЪег 8 (Аир 1998): равеѕ 
67 — 73. 


Зріаїпе, Ѕеуеп. Тезёте Иер Ѕеситйу. Мем Үогк: МПеу, 2002. 


544 


Библиография 


Зріаїпе, Ѕгехеп, её аі. Тле У/еб Тезіїпр Натабоі, Огапре Рагк, На: Ѕоймаге ОцаШу 
Епріпеегіпс Рибізпіпо, 2001. 


Згатагів, О. Н. Кайите Моде апа Ебесі Апаїузіз. Міїмачкее, Міѕс.: А50 Оиаїгу Ргезз, 
1995. 


Тарисіі, Сепісбі, апа Кајеѕћ Јиршит. "Ргіпсірієз ої Тариспі Месподз їог боймаге 
Тез". Ргосеейтру оў йе 5есота М/отіад Сопртез рот 5о/їшате диа у. Токуо: Опіоп ої 
Јарапеѕе Ѕсіепгіѕіѕ апа Епріпеегѕ, 2000. 


Тауюг, Егейегіск МіпзѕІом. Тйе Руйтсірівз оў Запис Мапаретті. 1911. 
Тоізкоу, Гео. Аппа Катепіпа. Мем Уогк: Модегп Г4Ьгагу, 2000. 


Тгірр, Геопага, ей. ТЕЕЕ 5о/їшате Епріпеегіпр Зіатаатаз СоПесйот, 1997 Кайіоп. Мем 
Уогк: ТЕЕЕ, 1997. 


Тике, Едмагд. Еплізіопіпр Гпјоттайоп. Сһеѕћіге, Сопп.: Старћісѕ Ргеѕѕ, 1990. 


Тобе, Едмага. Тһе Убиа Різріау о; Оиатшайие Іп/оттайот, Ѕесопа Ейійоп. СБезЫте, 
Сопп.: Старбіс5 Ргеѕѕ, 2001. 


Тобе, Еймага. Уѕиа/ Ехріапаййотз. Спезріге, Сопп.: Старһісѕ Ргеѕѕ, 1997. 
Там, Зип. Тре Ап оў Мат. Мем Уогк: Ре\асогіе Ргеѕѕ, 1983. 


Уапрогеп, Ейтопа. “СусІотайс Согпріехісу". боймаге Епріпеегіпо Іпѕсісиѓе'ѕ 
Зоймаге Тесһпоіору Кемеу. ммгм.5еї.спац.еди /5іг/ дезсгірйопз/ суфотайс_ 
БодуБипі. 


Уап УМеєпепдаа, Егік. Тһе Тезійпр Ргасййотет Оеп Воѕсһ, Мефейап4$: ОТМ 
Рифбіїзбег5, 2002. 


Уап Уеепепаалі, Егік, Воб Непагікз, апа ВоБег уап Уопдегеп. “Меаѕигіпр Ѕойуаге 
Ргодисі Оцаїйу диппр Теѕііпр”. Руо/е5зіопа! Теяет, Моїате 2, Іѕѕие 1 (Маг 2001): рареѕ 
26 — 30. 


Ұа!15һ, ]атез. Тте Оаа. Запта Мопіса, Саі: Меггіх РиЫіѕһію, 1996. 


М’аКоп, Магу. Тһе Ретіпр Мапаретепі Меіћой. Мем ХогК: Рипат Рибіїзбіпуя Сгочр, 
1986. 


УМеіпЬегр, Сегаїд М. Тйе Рзусћоіору оў Сотршет Реортаттітр. Мем Уотк: Уап Мозгап4 
Кеіпһо!а, 1971. 


М/’ешьегя, Сега М. Тйе Бестеіз оў Сопзиййтр. Мем УогК: Рогѕег Ноцзе, 1985. 
Мете, Је геу. Сияет. Мем УогК: Ѕіпоп & 5сПи5гег, 1996. 


МЛереге, Кагі. 5о/їшате Кедитетети. Ведтопа, Маѕћ.: Масгозой Ргеѕѕ, 1999. Есть рус- 
ский перевод: Вигерс К. Разработка требований к программному обеспечению. — 
М: Русская редакция, 2004. 

УУузоскі, КоБеге, Кобе Веск, Јг., апа раміа Сгапе. Еесвие Ргојесі Мапаретепі. Мем 
Үогк: УШеу, 1995. 


Хегох Согрогаїе ЕдисаНоп апа Тгаіпіпр. “Вепсһтагкіпр (ог ОцаШу Ітргоуетеп”. 
Теааеттр Тртоирй Опа. Ѕғатѓотга, Сопп: Хегох, 1989. 

Хегох Согрогае ЕдисаНоп апа Тгаіпіпр. "Сопсеріз ов Оцайту". Геадезмр ТћАтоирћ 
Оиаїйу. бат ога, Сопп: Хегох, 1988. 


Хегох Согрогме ЕдисаНоп апа Тгаіпіпо. “РгоМет-бо№ те Ргосеѕѕ”. Гвадетиар 
Тртоией Оцаїйу. Ѕєатѓога, Сопп: Хегох, 1986. 


Хегох Согрогае Едисайіоп апа Тгаіпіпр. “ОцаШу паргоуетегі Ргосез5”. Геадетзир 
Тртоисй Опа). 5:ахабога, Сопп: Хегох, 1988. 


Хоигдоп, Ед. Реаѓіћ Матсй. Оррег Заддіе Віуег, №: Ргеписе Най, 1999. Есть русский 
перевод: Йордон Э. Путь камикадзе. Второе издание. — М.: Лори, 2004. 


Разработка программного обеспечения/Тестирование 


Ключевые процессы 
тестирования 


"Рекс Блэк написал новую книгу, одну из тех, которую тестировщики 
читают от корки до корки, а затем часто ссылаются на нее." 


— Рик Крэйг, менеджер по тестированию программного обеспечения, автор книг, лектор и консультант 


В современных условиях стремительно меняющейся среды разработки процессы 
тестирования программного обеспечения играют все большую роль. Если методологии 
ускоренной разработки нацелены на потребность компании в быстром выпуске продукта, 
то процессы тестирования направлены на столь же существенную потребность в выпуске 
его в надлежащем виде. 


В этой книге Рекс Блэк, опираясь на свой богатый опыт, выделяет двенадцать процессов 
тестирования, являющихся ключевыми для достижения успеха. За описанием каждого 
из этих процессов следует отменно выстроенный пример использования процесса 

в различных организационных, операционных и технологических условиях. Вместо 
громоздких правил представлены списки контрольных вопросов — легкие, гибкие 
инструменты для внедрения тестирования, ориентированного на процесс, для сбора 
измерений и внесения последовательных изменений. 


Вы научитесь: 
• Наиболее эффективно и последовательно проводить тестирование 
® Собирать сплоченную, слаженно работающую команду 
> • Создавать репутацию надежности за счет эффективного предоставления результатов 


аи ния 


і. Книга даст вам новое представление о внутренних аспектах 
поможет лучше организовать работу. 


азйдент и ведущий консультант компании Вех В!аск Сопзбийіпд Ѕегуісеѕ, 
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